linux-kernel - Re: [RFC PATCH] mm: Replace ->launder

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 for Android: free password hash cracker in your pocket

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

Date: Tue, 19 Mar 2024 17:40:58 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: David Howells <dhowells@...hat.com>
Cc: Matthew Wilcox <willy@...radead.org>, Trond Myklebust <trond.myklebust@...merspace.com>, 
	Christoph Hellwig <hch@....de>, Andrew Morton <akpm@...ux-foundation.org>, 
	Alexander Viro <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>, 
	Jeff Layton <jlayton@...nel.org>, linux-mm@...ck.org, linux-fsdevel@...r.kernel.org, 
	netfs@...ts.linux.dev, v9fs@...ts.linux.dev, linux-afs@...ts.infradead.org, 
	ceph-devel@...r.kernel.org, linux-cifs@...r.kernel.org, 
	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] mm: Replace ->launder_folio() with flush and wait

On Tue, 19 Mar 2024 at 17:13, Miklos Szeredi <miklos@...redi.hu> wrote:
>
> On Tue, 19 Mar 2024 at 15:15, David Howells <dhowells@...hat.com> wrote:
>
> > What particular usage case of invalidate_inode_pages2() are you thinking of?
>
> FUSE_NOTIFY_INVAL_INODE will trigger invalidate_inode_pages2_range()
> to clean up the cache.
>
> The server is free to discard writes resulting from this invalidation
> and delay reads in the region until the invalidation finishes.  This
> would no longer work with your change, since the mapping could
> silently be reinstated between the writeback and the removal from the
> cache due to the page being unlocked/relocked.

This would also matter if a distributed filesystem wanted to implement
coherence even if there are mmaps.   I.e. a client could get exclusive
access to a region by issuing FUSE_NOTIFY_INVAL_INODE on all other
clients and blocking reads.  With your change this would fail.

Again, this is purely theoretical, and without a way to differentiate
between the read-only and write cases it has limited usefulness.
Adding leases to fuse (which I plan to do) would make this much more
useful.

Thanks,
Miklos