linux-kernel - Re: [PATCH v15 0/9] erofs: Introduce page cache sharing 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: <20260116153656.GA21174@lst.de>
Date: Fri, 16 Jan 2026 16:36:56 +0100
From: Christoph Hellwig <hch@....de>
To: Hongbo Li <lihongbo22@...wei.com>
Cc: hsiangkao@...ux.alibaba.com, chao@...nel.org, brauner@...nel.org,
	djwong@...nel.org, amir73il@...il.com, hch@....de,
	linux-fsdevel@...r.kernel.org, linux-erofs@...ts.ozlabs.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v15 0/9] erofs: Introduce page cache sharing feature

Sorry, just getting to this from my overful inbox by now.

On Fri, Jan 16, 2026 at 09:55:41AM +0000, Hongbo Li wrote:
> 2.1. file open & close
> ----------------------
> When the file is opened, the ->private_data field of file A or file B is
> set to point to an internal deduplicated file. When the actual read
> occurs, the page cache of this deduplicated file will be accessed.

So the first opener wins and others point to it?  That would lead to
some really annoying life time rules.  Or you allocate a hidden backing
file and have everyone point to it (the backing_file related subject
kinda hints at that), which would be much more sensible, but then the
above descriptions would not be correct.

> 
> When the file is opened, if the corresponding erofs inode is newly
> created, then perform the following actions:
> 1. add the erofs inode to the backing list of the deduplicated inode;
> 2. increase the reference count of the deduplicated inode.

This on the other hand suggests the fist opener is used approach again?

> Assuming the deduplication inode's page cache is PGCache_dedup, there

What is PGCache_dedup?

> Iomap and the layers below will involve disk I/O operations. As
> described in 2.1, the deduplicated inode itself is not bound to a
> specific device. The deduplicated inode will select an erofs inode from
> the backing list (by default, the first one) to complete the
> corresponding iomap operation.

What happens for mmap I/O where folio->mapping is kinda important?

Also do you have a git tree for the whole feature?