linux-kernel - Re: [PATCH v2 18/33] mnt: support ns lookup

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] [day] [month] [year] [list]

Message-ID: <20250917-garten-nirgendwo-f65f951a9268@brauner>
Date: Wed, 17 Sep 2025 11:50:29 +0200
From: Christian Brauner <brauner@...nel.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Jan Kara <jack@...e.cz>, Amir Goldstein <amir73il@...il.com>, 
	linux-fsdevel@...r.kernel.org, Josef Bacik <josef@...icpanda.com>, 
	Jeff Layton <jlayton@...nel.org>, Mike Yuan <me@...dnzj.com>, 
	Zbigniew Jędrzejewski-Szmek <zbyszek@...waw.pl>, Lennart Poettering <mzxreary@...inter.de>, 
	Daan De Meyer <daan.j.demeyer@...il.com>, Aleksa Sarai <cyphar@...har.com>, Jens Axboe <axboe@...nel.dk>, 
	Tejun Heo <tj@...nel.org>, Johannes Weiner <hannes@...xchg.org>, 
	Michal Koutný <mkoutny@...e.com>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
	Chuck Lever <chuck.lever@...cle.com>, linux-nfs@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	linux-block@...r.kernel.org, linux-kernel@...r.kernel.org, cgroups@...r.kernel.org, 
	netdev@...r.kernel.org
Subject: Re: [PATCH v2 18/33] mnt: support ns lookup

On Tue, Sep 16, 2025 at 05:46:48AM +0100, Al Viro wrote:
> On Tue, Sep 16, 2025 at 04:59:49AM +0100, Al Viro wrote:
> > On Tue, Sep 16, 2025 at 04:56:33AM +0100, Al Viro wrote:
> > > 	if (!RB_EMPTY_NODE(to_ns_common(ns)->ns_tree_node))
> > 
> >  	if (!RB_EMPTY_NODE(&to_ns_common(ns)->ns_tree_node))
> > 
> > obviously...
> 
> FWIW, how about the following - I put the commit below into never-rebased
> branch, pull it into #work.mount and you do the same to your branch
> just prior to 18/33?  The difference from one in #work.mount is that
> this variant checks RB_EMPTY_NODE(&ns->mnt_ns_tree_node) instead of
> list_empty(&ns->mnt_ns_list).  The reasons why it's safe lockless are
> pretty much the same...
> 
> Objections?  Does vfs/vfs.git #no-rebases-mnt_ns_tree_remove look sane
> for you?

Perfect, thank you!

> 
> mnt_ns_tree_remove(): DTRT if mnt_ns had never been added to mnt_ns_list
>     
> Actual removal is done under the lock, but for checking if need to bother
> the lockless RB_EMPTY_NODE() is safe - either that namespace had never
> been added to mnt_ns_tree, in which case the the node will stay empty, or
> whoever had allocated it has called mnt_ns_tree_add() and it has already
> run to completion.  After that point RB_EMPTY_NODE() will become false and
> will remain false, no matter what we do with other nodes in the tree.
>     
> Signed-off-by: Al Viro <viro@...iv.linux.org.uk>
> ---
> diff --git a/fs/namespace.c b/fs/namespace.c
> index ae6d1312b184..39afeb521a80 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -187,7 +187,7 @@ static void mnt_ns_release_rcu(struct rcu_head *rcu)
>  static void mnt_ns_tree_remove(struct mnt_namespace *ns)
>  {
>  	/* remove from global mount namespace list */
> -	if (!is_anon_ns(ns)) {
> +	if (!RB_EMPTY_NODE(&ns->mnt_ns_tree_node)) {
>  		mnt_ns_tree_write_lock();
>  		rb_erase(&ns->mnt_ns_tree_node, &mnt_ns_tree);
>  		list_bidir_del_rcu(&ns->mnt_ns_list);