From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout11.his.huawei.com (canpmsgout11.his.huawei.com [113.46.200.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 085D0354AF6; Tue, 20 Jan 2026 12:29:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.226 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768912157; cv=none; b=NJOVXcmszCalpUvOstgY0GhgLd9EsAWH+4FVzJjo6ZOTlVXI4Qg3IqBRgxKoIG0h0lwXH+mzwu+yMkDzB6uV3d5xCD8GE8vnaFMA+tQHOu94Bdbfp+LtjkajrSmjlnSg/llHzrASW/pDkaEfksp/dh5qi2idyddU+H+GkDh1Szc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768912157; c=relaxed/simple; bh=oWoGr8fnuGnNdrM1gukClrlPMV4k2yRkjSnnk6OnZA4=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=OShaUL4Lb1cXn1xDBoIgw6TNR9TeB1k/C2Dy0tCnkcBCB1q1bZkoRPDPzv1bHWKXIisKuJ1mMWKLc97mJ2bUssEMW58sPgjvqlxhAQgxAW6y6bF/2fCHdbwlw3+36ZLmbbWS/b7GtBUVanYxUUzDK7VZlQbOpesAeeDMFrDF8OA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=bmfDQUpM; arc=none smtp.client-ip=113.46.200.226 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="bmfDQUpM" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=RHupX/CGLY84XH8APP1wF5McWWipsb20eq77t+n+Xkw=; b=bmfDQUpMGWMtc+2KYoUEK080qnSyjhKYA5Qz+7QHvfrFjYKpkiYVx6PEJTq5eQsSWu4izlaWD PWG4zceSgQefIZUFhlwO0SAVj3oYK0djRvkpjZh3sa4Qfee4/xCaU+7jOyrklZ3Y8V7ncunFQlv BDIH0aVY5uk7fnfZrwq0Hxs= Received: from mail.maildlp.com (unknown [172.19.163.214]) by canpmsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4dwRPT4mMLzKm4c; Tue, 20 Jan 2026 20:25:49 +0800 (CST) Received: from kwepemr500015.china.huawei.com (unknown [7.202.195.162]) by mail.maildlp.com (Postfix) with ESMTPS id 984444056C; Tue, 20 Jan 2026 20:29:13 +0800 (CST) Received: from [10.67.111.104] (10.67.111.104) by kwepemr500015.china.huawei.com (7.202.195.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 20 Jan 2026 20:29:13 +0800 Message-ID: <5aa7566e-c30c-470a-ab77-8b62a3cdf8c3@huawei.com> Date: Tue, 20 Jan 2026 20:29:12 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v15 5/9] erofs: introduce the page cache share feature To: Christoph Hellwig CC: , , , , , , , References: <20260116095550.627082-1-lihongbo22@huawei.com> <20260116095550.627082-6-lihongbo22@huawei.com> <20260116154623.GC21174@lst.de> Content-Language: en-US From: Hongbo Li In-Reply-To: <20260116154623.GC21174@lst.de> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To kwepemr500015.china.huawei.com (7.202.195.162) On 2026/1/16 23:46, Christoph Hellwig wrote: > I don't really understand the fingerprint idea. Files with the > same content will point to the same physical disk blocks, so that > should be a much better indicator than a finger print? Also how does > the fingerprint guarantee uniqueness? Is it a cryptographically > secure hash? In here it just seems like an opaque blob. > >> +static inline int erofs_inode_set_aops(struct inode *inode, >> + struct inode *realinode, bool no_fscache) > > Factoring this out first would be a nice little prep patch. > Also it would probably be much cleaner using IS_ENABLED. Ok, Thanks for reviewing. I will refine in next version. Thanks, Hongbo > >> +static int erofs_ishare_file_open(struct inode *inode, struct file *file) >> +{ >> + struct inode *sharedinode = EROFS_I(inode)->sharedinode; > > Ok, it looks like this allocates a separate backing file and inode. >