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

[Ian Kent]

On 11/11/25 17:04, Al Viro wrote:
> 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))...

Not sure the motivation here is "we need a daemon in that namespace", it's

more my struggling to find a suitable check for the problem case even though

it does look a lot like what you say.


Thinking back the problem has always been the amount of stuff that's not

appropriate for the kernel, automount map parsing is pretty ugly, for 
example.


A better split of duties is probably what we would need to do.


But if we did that then we'd probably want to re-define/re-write the user

space <-> kernel space communications as well to assist with the division

of labour. In the beginning there was a proposal to do just that, not sure

I still have that stuff, I'll have a look around ... or do you have 
something

else specific in mind?


Anyway, for the moment, I think your saying just taking an ns_common 
reference

will be problematic as well.


Ian