On 18:51 27/09, Ian Kent wrote: > On Fri, 2019-09-27 at 15:41 +0800, Ian Kent wrote: > > > > > > I initially thought this was the result of a "fix" in the mount > > > > propagation code but it occurred to me that propagation is meant > > > > to occur between mount trees not within them so this might be a > > > > bug. > > > > > > > > I probably should have worked out exactly what upstream kernel > > > > this started happening in and then done a bisect and tried to > > > > work out if the change was doing what it was supposed to. > > > > > > > > Anyway, I'll need to do that now for us to discuss this sensibly. > > > > > > > > > > Signed-off-by: Goldwyn Rodrigues <rgoldwyn@xxxxxxxx> > > > > > > > > > > > > diff --git a/fs/pnode.c b/fs/pnode.c > > > > > > index 49f6d7ff2139..b960805d7954 100644 > > > > > > --- a/fs/pnode.c > > > > > > +++ b/fs/pnode.c > > > > > > @@ -292,6 +292,9 @@ int propagate_mnt(struct mount *dest_mnt, > > > > > > struct > > > > > > mountpoint *dest_mp, > > > > > > struct mount *m, *n; > > > > > > int ret = 0; > > > > > > > > > > > > + if (source_mnt->mnt_mountpoint->d_flags & > > > > > > DCACHE_NEED_AUTOMOUNT) > > > > > > + return 0; > > > > > > + > > > > > > > > > > Possible problem with this is it will probably prevent mount > > > > > propagation in both directions which will break stuff. No, I am specifically checking when the source has a automount flag set. It will block only one way. I checked it with an example. > > > > > > > > > > I had originally assumed the problem was mount propagation > > > > > back to the parent mount but now I'm not sure that this is > > > > > actually what is meant to happen. > > Goldwyn, > > TBH I'm already a bit over this particularly since it's a > solved problem from my POV. > > I've gone back as far as Fedora 20 and 3.11.10-301.fc20 also > behaves like this. The problem started with the root directory being mounted as shared. > > Unless someone says this behaviour is not the way kernel > mount propagation should behave I'm not going to spend > more time on it. > > The ability to use either "slave" or "private" autofs pseudo > mount options in master map mount entries that are susceptible > to this mount propagation behaviour was included in autofs-5.1.5 > and the patches used are present on kernel.org if you need to > back port them to an earlier release. What about "shared" pseudo mount option? The point is the default shared option with automount is broken, and should not be exposed at all. > > https://mirrors.edge.kernel.org/pub/linux/daemons/autofs/v5/patches-5.1.5/autofs-5.1.4-set-bind-mount-as-propagation-slave.patch > > https://mirrors.edge.kernel.org/pub/linux/daemons/autofs/v5/patches-5.1.5/autofs-5.1.4-add-master-map-pseudo-options-for-mount-propagation.patch > > It shouldn't be too difficult to back port them but they might > have other patch dependencies. I will help with that if you > need it. My problem is not with the patch and the "private" or "slave" flag, but with the absence of it. We have the patch you mention in our repos. I am assuming that users are stupid and they will miss putting the flags in the auto.master file and wonder why when they try to access the directories the process hangs. In all, any user configuration should not hang the kernel. My point is, if you don't have a automount map with the daemon, how can you propagate it and still be in control? I tried my experiments with 5.3.1 without "slave" or "private" flags and the process accessing the bind mount hangs. -- Goldwyn
