linux-kernel - Re: [PATCH v15 5/9] erofs: introduce the page cache share feature

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <af1f3ff6-a163-4515-92bf-44c9cf6c92f3@linux.alibaba.com>
Date: Sat, 17 Jan 2026 00:21:16 +0800
From: Gao Xiang <hsiangkao@...ux.alibaba.com>
To: Christoph Hellwig <hch@....de>, Hongbo Li <lihongbo22@...wei.com>
Cc: chao@...nel.org, brauner@...nel.org, djwong@...nel.org,
 amir73il@...il.com, linux-fsdevel@...r.kernel.org,
 linux-erofs@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v15 5/9] erofs: introduce the page cache share feature

Hi Christoph,

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

Page cache sharing should apply to different EROFS
filesystem images on the same machine too, so the
physical disk block number idea cannot be applied
to this.

> the fingerprint guarantee uniqueness?  Is it a cryptographically
> secure hash?  In here it just seems like an opaque blob.

Yes, typically it can be a secure hash like sha256,
but it really depends on the users how to use it.

This feature is enabled _only_ when a dedicated mount
option is used, and should be enabled by the priviledged
mounters, and it's up to the priviledged mounters to
guarantee the fingerprint is correct (usually guaranteed
by signatures by image builders since images will be
signed).

Also different signatures also can be isolated by domain
ids, so that different domain ids cannot be shared.

> 
>> +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.
> 
>> +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.

Yes.

Thanks,
Gao Xiang