linux-kernel - Re: [PATCH v6 00/15] Create and use APIs to centralise locking for directory ops

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: <3209fb8c9be25362316bf3585a156c21f3b0a7e2.camel@kernel.org>
Date: Fri, 14 Nov 2025 09:52:59 -0500
From: Jeff Layton <jlayton@...nel.org>
To: Christian Brauner <brauner@...nel.org>, NeilBrown <neil@...wn.name>
Cc: Alexander Viro <viro@...iv.linux.org.uk>, Amir Goldstein	
 <amir73il@...il.com>, Jan Kara <jack@...e.cz>,
 linux-fsdevel@...r.kernel.org,  Chris Mason	 <clm@...com>, David Sterba
 <dsterba@...e.com>, David Howells <dhowells@...hat.com>,  Greg
 Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J. Wysocki"
 <rafael@...nel.org>, Danilo Krummrich	 <dakr@...nel.org>, Tyler Hicks
 <code@...icks.com>, Miklos Szeredi	 <miklos@...redi.hu>, Chuck Lever
 <chuck.lever@...cle.com>, Olga Kornievskaia	 <okorniev@...hat.com>, Dai Ngo
 <Dai.Ngo@...cle.com>, Namjae Jeon	 <linkinjeon@...nel.org>, Steve French
 <smfrench@...il.com>, Sergey Senozhatsky	 <senozhatsky@...omium.org>,
 Carlos Maiolino <cem@...nel.org>, John Johansen	
 <john.johansen@...onical.com>, Paul Moore <paul@...l-moore.com>, James
 Morris	 <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>, Stephen
 Smalley	 <stephen.smalley.work@...il.com>, Ondrej Mosnacek
 <omosnace@...hat.com>,  Mateusz Guzik <mjguzik@...il.com>, Lorenzo Stoakes
 <lorenzo.stoakes@...cle.com>, Stefan Berger	 <stefanb@...ux.ibm.com>,
 "Darrick J. Wong" <djwong@...nel.org>, 	linux-kernel@...r.kernel.org,
 netfs@...ts.linux.dev, ecryptfs@...r.kernel.org, 
	linux-nfs@...r.kernel.org, linux-unionfs@...r.kernel.org, 
	linux-cifs@...r.kernel.org, linux-xfs@...r.kernel.org, 
	linux-security-module@...r.kernel.org, selinux@...r.kernel.org
Subject: Re: [PATCH v6 00/15] Create and use APIs to centralise locking for
 directory ops

On Fri, 2025-11-14 at 15:23 +0100, Christian Brauner wrote:
> On Fri, Nov 14, 2025 at 01:24:41PM +0100, Christian Brauner wrote:
> > On Thu, Nov 13, 2025 at 11:18:23AM +1100, NeilBrown wrote:
> > > Following is a new version of this series:
> > >  - fixed a bug found by syzbot
> > >  - cleanup suggested by Stephen Smalley
> > >  - added patch for missing updates in smb/server - thanks Jeff Layton
> > 
> > The codeflow right now is very very gnarly in a lot of places which
> > obviously isn't your fault. But start_creating() and end_creating()
> > would very naturally lend themselves to be CLASS() guards.
> >
> > Unrelated: I'm very inclined to slap a patch on top that renames
> > start_creating()/end_creating() and start_dirop()/end_dirop() to
> > vfs_start_creating()/vfs_end_creating() and
> > vfs_start_dirop()/vfs_end_dirop(). After all they are VFS level
> > maintained helpers and I try to be consistent with the naming in the
> > codebase making it very easy to grep.
> 
> @Neil, @Jeff, could you please look at:
> https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/log/?h=vfs.all
> 
> and specifically at the merge conflict resolution I did for:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/commit/?h=vfs.all&id=f28c9935f78bffe6fee62f7fb9f6c5af7e30d9b2
> 
> and tell me whether it all looks sane?


I don't see any major issues. I'm kicking off a quick pynfs test run
now with it. One fairly minor nit:

@@ -212,15 +210,13 @@ nfsd4_create_clid_dir(struct nfs4_client *clp)
 		 * In the 4.0 case, we should never get here; but we may
 		 * as well be forgiving and just succeed silently.
 		 */
-		goto out_put;
-	dentry = vfs_mkdir(&nop_mnt_idmap, d_inode(dir), dentry, 0700, NULL);
+		goto out_end;
+	dentry = vfs_mkdir(&nop_mnt_idmap, d_inode(dir), dentry, S_IRWXU, NULL);
 	if (IS_ERR(dentry))
 		status = PTR_ERR(dentry);

I'm not sure if it was Neil's patch or your resolution that changed it,
but the change from 0700 to a symbolic constant is not preferred, IMO.
File modes are one of the few places where I think it's easier to
interpret (octal) numbers rather than symbolic constants.

-- 
Jeff Layton <jlayton@...nel.org>