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: <20260122083310.GA27928@lst.de>
Date: Thu, 22 Jan 2026 09:33:10 +0100
From: Christoph Hellwig <hch@....de>
To: Gao Xiang <hsiangkao@...ux.alibaba.com>
Cc: Christoph Hellwig <hch@....de>, Hongbo Li <lihongbo22@...wei.com>,
	chao@...nel.org, djwong@...nel.org, amir73il@...il.com,
	linux-fsdevel@...r.kernel.org, linux-erofs@...ts.ozlabs.org,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Christian Brauner <brauner@...nel.org>,
	oliver.yang@...ux.alibaba.com
Subject: Re: [PATCH v15 5/9] erofs: introduce the page cache share feature

On Tue, Jan 20, 2026 at 03:19:21PM +0800, Gao Xiang wrote:
>> It will be very hard to change unless we move to physical indexing of
>> the page cache, which has all kinds of downside.s
>
> I'm not sure if it's really needed: I think the final
> folio adaption plan is that folio can be dynamic
> allocated? then why not keep multiple folios for a
> physical memory, since folios are not order-0 anymore.

Having multiple folios for the same piece of memory can't work,
at we'd have unsynchronized state.

> Using physical indexing sounds really inflexible on my
> side, and it can be even regarded as a regression for me.

I'm absolutely not arguing for that..

>>> So that let's face the reality: this feature introduces
>>> on-disk xattrs called "fingerprints." --- Since they're
>>> just xattrs, the EROFS on-disk format remains unchanged.
>>
>> I think the concept of using a backing file of some sort for the shared
>> pagecache (which I have no problem with at all), vs the imprecise
>
> In that way (actually Jingbo worked that approach in 2023),
> we have to keep the shared data physically contiguous and
> even uncompressed, which cannot work for most cases.

Why does that matter?

> On the other side, I do think `fingerprint` from design
> is much like persistent NFS file handles in some aspect
> (but I don't want to equal to that concept, but very
> similar) for a single trusted domain, we should have to
> deal with multiple filesystem sources and mark in a
> unique way in a domain.

I don't really thing they are similar in any way.