All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Kent <raven@themaw.net>
To: Goldwyn Rodrigues <rgoldwyn@suse.de>, viro@zeniv.linux.org.uk
Cc: autofs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [RFC] Don't propagate automount
Date: Fri, 27 Sep 2019 18:51:52 +0800	[thread overview]
Message-ID: <b2443a28939d6fe79ec9aa9d983f516c8269448a.camel@themaw.net> (raw)
In-Reply-To: <7f31f0c2bf214334a8f7e855044c88a50e006f05.camel@themaw.net>

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@suse.com>
> > > > > 
> > > > > 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.
> > > > 
> > > > 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.

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.

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.

Ian


  reply	other threads:[~2019-09-27 10:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-26 19:52 [RFC] Don't propagate automount Goldwyn Rodrigues
2019-09-27  1:35 ` Ian Kent
2019-09-27  7:09   ` Ian Kent
2019-09-27  7:26     ` Ian Kent
2019-09-27  7:41       ` Ian Kent
2019-09-27 10:51         ` Ian Kent [this message]
2019-09-27 16:16           ` Goldwyn Rodrigues
2019-09-28  1:47             ` Ian Kent
2019-10-01 19:09               ` Goldwyn Rodrigues
2019-10-02  2:14                 ` Ian Kent
2019-10-28 16:28                   ` Goldwyn Rodrigues
2019-10-28 23:57                     ` Ian Kent
2019-10-29  6:39                       ` Ian Kent
2019-10-29  6:40                         ` Ian Kent
2019-10-29 16:00                         ` Goldwyn Rodrigues
2019-10-30  6:01                           ` Ian Kent
2019-10-30  6:05                             ` Ian Kent
2019-10-30 12:05                           ` Ian Kent
2019-10-30 19:28                             ` Goldwyn Rodrigues

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b2443a28939d6fe79ec9aa9d983f516c8269448a.camel@themaw.net \
    --to=raven@themaw.net \
    --cc=autofs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=rgoldwyn@suse.de \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.