linux-kernel - Re: [PATCH 0/5] Minor cleanup preparation for some dir-locking API changes

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: <174968131051.608730.6876830326454616279@noble.neil.brown.name>
Date: Thu, 12 Jun 2025 08:35:10 +1000
From: "NeilBrown" <neil@...wn.name>
To: "Christian Brauner" <brauner@...nel.org>
Cc: "Alexander Viro" <viro@...iv.linux.org.uk>, "Jan Kara" <jack@...e.cz>,
 "Chuck Lever" <chuck.lever@...cle.com>, "Jeff Layton" <jlayton@...nel.org>,
 "Amir Goldstein" <amir73il@...il.com>, "Jan Harkes" <jaharkes@...cmu.edu>,
 "David Howells" <dhowells@...hat.com>, "Tyler Hicks" <code@...icks.com>,
 "Miklos Szeredi" <miklos@...redi.hu>, "Carlos Maiolino" <cem@...nel.org>,
 linux-fsdevel@...r.kernel.org, coda@...cmu.edu, codalist@...a.cs.cmu.edu,
 linux-nfs@...r.kernel.org, netfs@...ts.linux.dev, ecryptfs@...r.kernel.org,
 linux-unionfs@...r.kernel.org, linux-xfs@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject:
 Re: [PATCH 0/5] Minor cleanup preparation for some dir-locking API changes

On Wed, 11 Jun 2025, Christian Brauner wrote:
> On Mon, Jun 09, 2025 at 09:09:32AM +1000, NeilBrown wrote:
> > The following 5 patches provide further cleanup that serves as
> > preparation for some dir-locking API changes that I want to make.  The
> > most interesting is the last which makes another change to vfs_mkdir().
> > As well as returning the dentry or consuming it on failure (a recent
> > change) it now also unlocks on failure.  This will be needed when we
> > transition to locking just the dentry, not the whole directory.
> 
> All of the patches except the vfs_mkdir() one that Al is looking at
> make sense as independent cleanups imho. So I'd take them unless I hear
> screams.
> 

Thanks.  I'm glad you didn't include the vfs_mkdir() change as I found a
problem in the overlayfs code.  I'm make sure I really understand that
code before trying that one again.

Meanwhile I noticed I have a couple of other mostly-independent
cleanups.  I'll send those.

NeilBrown