On Sat, 11 Mar 2023, Ian Kent wrote:
> On 11/3/23 14:26, Ian Kent wrote:
> > On 9/3/23 17:23, NeilBrown wrote:
> >> On Thu, 09 Mar 2023, Ian Kent wrote:
> >>> On 8/3/23 13:52, NeilBrown wrote:
> >>>> New flags in the master map:
> >>>> autofsshared
> >>>> autofsprivate
> >>>> autofsslave
> >>>>
> >>>> cause the corresponding mount propagation flags to be set on the
> >>>> autofs
> >>>> mount point. If none are specified the current behaviour of
> >>>> inheriting
> >>>> from the parent unchanged.
> >>>>
> >>>> For example specify "autofsprivate" allows mount points to be moved
> >>>> away from autofs using "mount -M .....". This is not supported by the
> >>>> kernel for the normal default of "shared".
> >>>>
> >>>> Better flag names should be chosen. I would have liked to use
> >>>> "shared",
> >>>> "private", and "slave", but they are already in use and only affect
> >>>> bind
> >>>> mounts.
> >>> Looks fine, I'll add it to my patch queue, can't say when I'll commit
> >>>
> >>> them though. If you need it committed sooner let me know.
> >> No rush at all - that fact that you don't hate it is enough for now.
> >> I was hoping you *would* hate the flag names I chose and would suggest
> >> something better.
> >
> > I think your suggesting merging this with the existing code, that's were
> >
> > I was going too.
> >
> >
> >> After pondering some more the best I can think of is
> >>
> >> private-autofs
> >> etc.
> >> Can you think of anything better?
> >>
> >> maybe
> >> private=autofs
> >> which could later be extended to a list of filesystem types...
> >>
> >> My other thought is that if they autofs mount is "private" then that is
> >> inherited to all descendants including the "bind" mounts. So if we
> >> changed "private" to apply to the autofs mounts rather than just the
> >> bind mounts, then it would still affect the bind mounts as documented,
> >> but it would affect more as well.... I guess that would end up
> >> negatively affecting someone though...
> >
> > I can't remember now the motivation for what I originally did.
> >
> >
> > I'll need to look at that but I suspect it's similar, if not
> >
> > the same, as your reasons for needing it. I should get a bit
> >
> > of time soon to have a look ...
>
> It looks like the only thing to worry about if we decide to merge
>
> the existing propagation options and these is whether we check
>
> and stop people from shooting themselves in the foot by causing
>
> a deadlock and working out if there are other cases of deadlock
>
> beside bind mounting.
>
I'm not sure that I understand the cause of the deadlock.
I assume it happens when an autofs mount appears somewhere that the
automount daemon doesn't know about, and when propagation is configured
so that when automount mounts something on the location it *does* know
about, the mount isn't propagated to the problem location.
And access of that problem location would then block waiting for the
automount daemon to mount something, but it never will.
Is that correct? Is that the only problem?
So if automount bind-mounts something from elsewhere over an autofs
mount point, it doesn't want any autofs mount points is mounts below
this to be propagated back to the origin. This is why it defaults to
"slave". That makes sense. It would be safe for mounts to propagate
back only of the original mount was shared or slave - be we cannot check
or enforce that.
Though if the first autofs mount point were already private, then it
should probably leave the child bind-mount as private rather than change
it to slave.
It feels like there is a lot of potential for problems if someone
creates a bind mount from an automount-manager tree and makes it
private, or if the original tree is private. So maybe we shouldn't
support "private" autofs mounts. They should be shared, slave, or
unbindable.
Similarly slave autofs mounts would be a problem as if they are
bind-mounted to somewhere (or just duplicated into a new namespace).
Changes made by automount wouldn't propagate elsewhere and so deadlocks
could happen.
So maybe the autofs mounts should always be either shared or unbindable.
When autofs mounts a new filesystem on an autofs mount it can safely
inherit from the parent. However when it bind-mounts an existing
filesystem it needs to ensure it is at most "slave".
So I can see two sensible options.
1/ The autofs mount is "shared" if parent is shared, and is
unbindable otherwise.
bind-mounts are "slave" if the parent is shared, or
unbindable otherwise
2/ Everything is unbindable. This could be achieved with the "private"
option.
I guess that we still need to support "shared" with leaves bind mounts
as shared, but with a warning that deadlocks can occur if used
carelessly.
Have I missed anything important?
Thanks,
NeilBrown
