linux-kernel - Re: [PATCH 00/10] convert the majority of file systems to mmap

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]

Message-ID: <tz4x7atqjhxr3rixvgklfss4r5u5jod5qoeqr6iueois3ywdap@losa5evtlekp>
Date: Mon, 16 Jun 2025 15:56:11 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-block@...r.kernel.org, 
	linux-kernel@...r.kernel.org, intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org, 
	v9fs@...ts.linux.dev, linux-fsdevel@...r.kernel.org, linux-afs@...ts.infradead.org, 
	linux-aio@...ck.org, linux-unionfs@...r.kernel.org, linux-bcachefs@...r.kernel.org, 
	linux-mm@...ck.org, linux-btrfs@...r.kernel.org, ceph-devel@...r.kernel.org, 
	codalist@...a.cs.cmu.edu, ecryptfs@...r.kernel.org, linux-erofs@...ts.ozlabs.org, 
	linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net, 
	linux-um@...ts.infradead.org, linux-mtd@...ts.infradead.org, 
	jfs-discussion@...ts.sourceforge.net, linux-nfs@...r.kernel.org, linux-nilfs@...r.kernel.org, 
	ntfs3@...ts.linux.dev, ocfs2-devel@...ts.linux.dev, 
	linux-karma-devel@...ts.sourceforge.net, devel@...ts.orangefs.org, linux-cifs@...r.kernel.org, 
	samba-technical@...ts.samba.org, linux-xfs@...r.kernel.org, nvdimm@...ts.linux.dev
Subject: Re: [PATCH 00/10] convert the majority of file systems to
 mmap_prepare

Mailserver is rejecting with "too many recipients" - aieeee

On Mon, Jun 16, 2025 at 08:33:19PM +0100, Lorenzo Stoakes wrote:
> REVIEWER'S NOTES
> ================
> 
> I am basing this on the mm-new branch in Andrew's tree, so let me know if I
> should rebase anything here. Given the mm bits touched I did think perhaps
> we should take it through the mm tree, however it may be more sensible to
> take it through an fs tree - let me know!
> 
> Apologies for the noise/churn, but there are some prerequisite steps here
> that inform an ordering - "fs: consistently use file_has_valid_mmap_hooks()
> helper" being especially critical, and so I put the bulk of the work in the
> same series.
> 
> Let me know if there's anything I can do to make life easier here.

This seems to be more of an mm thing than a filesystem thing? I don't
see any code changes on the filesystem side from a quick scan, just
renaming?

Are there any behavioural changes for the filesystem to be aware of?

How's it been tested, any considerations there?

If this is as simple as it looks, ack from me (and if it is that simply,
why so many recipients?).

If there are _any_ behavioural changes on the mm side that might
interact with the filesystem in funny ways, please make sure the whole
fstests suite has been run.