Re: [PATCH 4/9] fs: unmount without a grace period when nothing else holds the mounts

[Al Viro <viro@zeniv.linux.org.uk>]

On Mon, Oct 12, 2026 at 05:39:17PM +0200, Christian Brauner wrote:

>  fs/namespace.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++++---------
>  1 file changed, 79 insertions(+), 13 deletions(-)
> 
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 8c6673bd8c03..435e5f6db880 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -1489,10 +1489,12 @@ static void mntput_no_expire(struct mount *mnt)
>  		 * Since we don't do lock_mount_hash() here,
>  		 * ->mnt_ns can change under us.  However, if it's
>  		 * non-NULL, then there's a reference that won't
> -		 * be dropped until after an RCU delay done after
> -		 * turning ->mnt_ns NULL.  So if we observe it
> -		 * non-NULL under rcu_read_lock(), the reference
> -		 * we are dropping is not the final one.
> +		 * be dropped until after turning ->mnt_ns NULL and
> +		 * either an RCU delay or a look under mount_lock
> +		 * that found it to be the only one left, which it
> +		 * isn't while ours is counted (mntput_unheld()).

Umm....   something like "either an RCU delay or having mntput_unheld()
observe the refcount to be 1 in a mount_lock exclusive scope.  The latter
can't happen until the mnt_dec_count() below", perhaps?  Probably still
too convoluted...

I'm not trying to nitpick - the place _is_ subtle and we are pretty
much guaranteed to look at it quite a few times down the road...

So basically you are relying upon the following:
1) RCU references to mounts are only used inside RCU read-side
critical scopes that have
	* mount_lock sampled prior to having observed the mount
in a live state
	* __legitimize_mnt() with the sampled value of mount_lock
done to obtain a counting reference
2) there's an RCU delay between having been observed live and freeing.
3) ->mnt_parent of a something that had been live in an RCU scope will
point to something that had been live in the same RCU scope.
4) ->root.mnt and ->pwd.mnt observed under ->seq are live.
5) anything observed in mount hash under mount_lock is live.

Might work...  FWIW, I wonder (again) if we should replace the check for
mnt->mnt.mnt_flags & MNT_DOOMED in the slow path of mntput_no_expire()
with WARN_ON() - it really should never happen.