linux-kernel - Re: [PATCH 01/13] fs/proc: Don't lock root inode when creating "self" and "thread-self"

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: <b62d43c08545d26772a5fff45f13832767d766bb.camel@kernel.org>
Date: Thu, 05 Feb 2026 07:33:26 -0500
From: Jeff Layton <jlayton@...nel.org>
To: NeilBrown <neil@...wn.name>, Christian Brauner <brauner@...nel.org>, 
 Alexander Viro <viro@...iv.linux.org.uk>, David Howells
 <dhowells@...hat.com>, Jan Kara <jack@...e.cz>, Chuck Lever
 <chuck.lever@...cle.com>, Miklos Szeredi <miklos@...redi.hu>, Amir
 Goldstein	 <amir73il@...il.com>, 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>
Cc: linux-kernel@...r.kernel.org, netfs@...ts.linux.dev, 
	linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org, 
	linux-unionfs@...r.kernel.org, apparmor@...ts.ubuntu.com, 
	linux-security-module@...r.kernel.org, selinux@...r.kernel.org
Subject: Re: [PATCH 01/13] fs/proc: Don't lock root inode when creating
 "self" and "thread-self"

On Wed, 2026-02-04 at 15:57 +1100, NeilBrown wrote:
> From: NeilBrown <neil@...wn.name>
> 
> proc_setup_self() and proc_setup_thread_self() are only called from
> proc_fill_super() which is before the filesystem is "live".  So there is
> no need to lock the root directory when adding "self" and "thread-self".
> This is clear from simple_fill_super() which provides similar
> functionality for other filesystems and does not lock anything.
> 
> The locking is not harmful, except that it may be confusing to a reader.
> As part of a an effort to centralise all locking for directories for
> name-based operations (prior to changing some locking rules), it is
> simplest to remove the locking here.
> 
> Signed-off-by: NeilBrown <neil@...wn.name>
> ---
>  fs/proc/self.c        | 3 ---
>  fs/proc/thread_self.c | 3 ---
>  2 files changed, 6 deletions(-)
> 
> diff --git a/fs/proc/self.c b/fs/proc/self.c
> index 62d2c0cfe35c..56adf1c68f7a 100644
> --- a/fs/proc/self.c
> +++ b/fs/proc/self.c
> @@ -35,11 +35,9 @@ unsigned self_inum __ro_after_init;
>  
>  int proc_setup_self(struct super_block *s)
>  {
> -	struct inode *root_inode = d_inode(s->s_root);
>  	struct dentry *self;
>  	int ret = -ENOMEM;
>  
> -	inode_lock(root_inode);
>  	self = d_alloc_name(s->s_root, "self");
>  	if (self) {
>  		struct inode *inode = new_inode(s);
> @@ -55,7 +53,6 @@ int proc_setup_self(struct super_block *s)
>  		}
>  		dput(self);
>  	}
> -	inode_unlock(root_inode);
>  
>  	if (ret)
>  		pr_err("proc_fill_super: can't allocate /proc/self\n");
> diff --git a/fs/proc/thread_self.c b/fs/proc/thread_self.c
> index d6113dbe58e0..61ac62c3fd9f 100644
> --- a/fs/proc/thread_self.c
> +++ b/fs/proc/thread_self.c
> @@ -35,11 +35,9 @@ unsigned thread_self_inum __ro_after_init;
>  
>  int proc_setup_thread_self(struct super_block *s)
>  {
> -	struct inode *root_inode = d_inode(s->s_root);
>  	struct dentry *thread_self;
>  	int ret = -ENOMEM;
>  
> -	inode_lock(root_inode);
>  	thread_self = d_alloc_name(s->s_root, "thread-self");
>  	if (thread_self) {
>  		struct inode *inode = new_inode(s);
> @@ -55,7 +53,6 @@ int proc_setup_thread_self(struct super_block *s)
>  		}
>  		dput(thread_self);
>  	}
> -	inode_unlock(root_inode);
>  
>  	if (ret)
>  		pr_err("proc_fill_super: can't allocate /proc/thread-self\n");

Reviewed-by: Jeff Layton <jlayton@...nel.org>