Re: [PATCH 2/2] autofs: dont trigger mount if it cant succeed

[Al Viro]

On Tue, Nov 11, 2025 at 04:25:29PM +0800, Ian Kent wrote:

> > Huh?  What's to guarantee that superblock won't outlive the namespace?
> 
> Not 30 minutes after I posted these I was thinking about the case the daemon
> 
> (that mounted this) going away, very loosely similar I think. Setting the
> 
> mounting process's namespace when it mounts it is straight forward but what
> 
> can I do if the process crashes ...
> 
> 
> I did think that if the namespace is saved away by the process that mounts
> 
> it that the mount namespace would be valid at least until it umounts it but
> 
> yes there are a few things that can go wrong ...

Umm...

1) super_block != mount; unshare(CLONE_NEWNS) by anyone in the namespace of
that mount *will* create a clone of that mount, with exact same ->mnt_sb
and yes, in a separate namespace.

2) mount does not pin a namespace.  chdir into it, umount -l and there you go...

3) mount(2) can bloody well create more than one struct mount, all with the
same ->mnt_sb.

So I'd say there's more than a few things that can go wrong here.

Said that, this "we need a daemon in that namespace" has been a source of
assorted headaches for decades now; could we do anything about that?
After all, a thread can switch from one namespace to another these
days (setns(2))...