All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Kent <raven@themaw.net>
To: Goldwyn Rodrigues <rgoldwyn@suse.de>
Cc: viro@zeniv.linux.org.uk, autofs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [RFC] Don't propagate automount
Date: Wed, 30 Oct 2019 14:05:48 +0800	[thread overview]
Message-ID: <6422274be72dd4fe99978122553f991adbb5ec0c.camel@themaw.net> (raw)
In-Reply-To: <a7e2d30f30f435216e9533d79928e6cf2e953256.camel@themaw.net>

On Wed, 2019-10-30 at 14:01 +0800, Ian Kent wrote:
> On Tue, 2019-10-29 at 11:00 -0500, Goldwyn Rodrigues wrote:
> > On 14:39 29/10, Ian Kent wrote:
> > > On Tue, 2019-10-29 at 07:57 +0800, Ian Kent wrote:
> > > > On Mon, 2019-10-28 at 11:28 -0500, Goldwyn Rodrigues wrote:
> > > > > Hi Ian,
> > > > > 
> > > > > On 10:14 02/10, Ian Kent wrote:
> > > > > > On Tue, 2019-10-01 at 14:09 -0500, Goldwyn Rodrigues wrote:
> > > > > <snip>
> > > > > 
> > > > > > Anyway, it does sound like it's worth putting time into
> > > > > > your suggestion of a kernel change.
> > > > > > 
> > > > > > Unfortunately I think it's going to take a while to work
> > > > > > out what's actually going on with the propagation and I'm
> > > > > > in the middle of some other pressing work right now.
> > > > > 
> > > > > Have you have made any progress on this issue?
> > > > 
> > > > Sorry I haven't.
> > > > I still want to try and understand what's going on there.
> > > > 
> > > > > As I mentioned, I am fine with a userspace solution of
> > > > > defaulting
> > > > > to slave mounts all of the time instead of this kernel patch.
> > > > 
> > > > Oh, I thought you weren't keen on that recommendation.
> > > > 
> > > > That shouldn't take long to do so I should be able to get that
> > > > done
> > > > and post a patch pretty soon.
> > > > 
> > > > I'll get back to looking at the mount propagation code when I
> > > > get
> > > > a
> > > > chance. Unfortunately I haven't been very successful when
> > > > making
> > > > changes to that area of code in the past ...
> > > 
> > > After working on this patch I'm even more inclined to let the
> > > kernel
> > > do it's propagation thing and set the autofs mounts, either
> > > silently
> > > by default or explicitly by map entry option.
> > > 
> > > Because it's the propagation setting of the parent mount that
> > > controls
> > > the propagation of its children there shouldn't be any chance of
> > > a
> > > race so this should be reliable.
> > > 
> > > Anyway, here is a patch, compile tested only, and without the
> > > changelog
> > > hunk I normally add to save you possible conflicts. But unless
> > > there
> > > are any problems found this is what I will eventually commit to
> > > the
> > > repo.
> > > 
> > > If there are any changes your not aware of I'll let you know.
> > > 
> > > Clearly this depends on the other two related patches for this
> > > issue.
> > 
> > This works good for us. Thanks.
> > However, I have some review comments for the patch.
> > 
> > > --
> > > 
> > > autofs-5.1.6 - make bind mounts propagation slave by default
> > > 
> > > From: Ian Kent <raven@themaw.net>
> > > 
> > > Make setting mount propagation on bind mounts mandatory with a
> > > default
> > > of propagation slave.
> > > 
> > > When using multi-mounts that have bind mounts the bind mount will
> > > have
> > > the same properties as its parent which is commonly propagation
> > > shared.
> > > And if the mount target is also propagation shared this can lead
> > > to
> > > a
> > > deadlock when attempting to access the offset mounts. When this
> > > happens
> > > an unwanted offset mount is propagated back to the target file
> > > system
> > > resulting in a deadlock since the automount target is itself an
> > > (unwanted) automount trigger.
> > > 
> > > This problem has been present much longer than I originally
> > > thought,
> > > perhaps since mount propagation was introduced into the kernel,
> > > so
> > > explicitly setting bind mount propagation is the sensible thing
> > > to
> > > do.
> > > 
> > > Signed-off-by: Ian Kent <raven@themaw.net>
> > > ---
> > >  include/automount.h  |    9 +++++----
> > >  lib/master_parse.y   |   11 ++++++++---
> > >  lib/master_tok.l     |    1 +
> > >  man/auto.master.5.in |   19 ++++++++++---------
> > >  modules/mount_bind.c |   40 ++++++++++++++++++++++--------------
> > > ----
> > >  5 files changed, 46 insertions(+), 34 deletions(-)
> > > 
> > > diff --git a/include/automount.h b/include/automount.h
> > > index 4fd0ba96..fe9c7fee 100644
> > > --- a/include/automount.h
> > > +++ b/include/automount.h
> > > @@ -551,14 +551,15 @@ struct kernel_mod_version {
> > >  #define MOUNT_FLAG_AMD_CACHE_ALL	0x0080
> > >  
> > >  /* Set mount propagation for bind mounts */
> > > -#define MOUNT_FLAG_SLAVE		0x0100
> > > -#define MOUNT_FLAG_PRIVATE		0x0200
> > > +#define MOUNT_FLAG_SHARED		0x0100
> > > +#define MOUNT_FLAG_SLAVE		0x0200
> > > +#define MOUNT_FLAG_PRIVATE		0x0400
> > >  
> > >  /* Use strict expire semantics if requested and kernel supports
> > > it
> > > */
> > > -#define MOUNT_FLAG_STRICTEXPIRE		0x0400
> > > +#define MOUNT_FLAG_STRICTEXPIRE		0x0800
> > >  
> > >  /* Indicator for applications to ignore the mount entry */
> > > -#define MOUNT_FLAG_IGNORE		0x0800
> > > +#define MOUNT_FLAG_IGNORE		0x1000
> > >  
> > >  struct autofs_point {
> > >  	pthread_t thid;
> > > diff --git a/lib/master_parse.y b/lib/master_parse.y
> > > index f817f739..e9589a5a 100644
> > > --- a/lib/master_parse.y
> > > +++ b/lib/master_parse.y
> > > @@ -59,6 +59,7 @@ static long timeout;
> > >  static long negative_timeout;
> > >  static unsigned symlnk;
> > >  static unsigned strictexpire;
> > > +static unsigned shared;
> > >  static unsigned slave;
> > >  static unsigned private;
> > >  static unsigned nobind;
> > > @@ -106,7 +107,7 @@ static int master_fprintf(FILE *, char *,
> > > ...);
> > >  %token MAP
> > >  %token OPT_TIMEOUT OPT_NTIMEOUT OPT_NOBIND OPT_NOGHOST OPT_GHOST
> > > OPT_VERBOSE
> > >  %token OPT_DEBUG OPT_RANDOM OPT_USE_WEIGHT OPT_SYMLINK OPT_MODE
> > > -%token OPT_STRICTEXPIRE OPT_SLAVE OPT_PRIVATE
> > > +%token OPT_STRICTEXPIRE OPT_SHARED OPT_SLAVE OPT_PRIVATE
> > >  %token COLON COMMA NL DDASH
> > >  %type <strtype> map
> > >  %type <strtype> options
> > > @@ -208,6 +209,7 @@ line:
> > >  	| PATH OPT_TIMEOUT { master_notify($1); YYABORT; }
> > >  	| PATH OPT_SYMLINK { master_notify($1); YYABORT; }
> > >  	| PATH OPT_STRICTEXPIRE { master_notify($1); YYABORT; }
> > > +	| PATH OPT_SHARED { master_notify($1); YYABORT; }
> > >  	| PATH OPT_SLAVE { master_notify($1); YYABORT; }
> > >  	| PATH OPT_PRIVATE { master_notify($1); YYABORT; }
> > >  	| PATH OPT_NOBIND { master_notify($1); YYABORT; }
> > > @@ -622,6 +624,7 @@ daemon_option: OPT_TIMEOUT NUMBER { timeout =
> > > $2; }
> > >  	| OPT_NTIMEOUT NUMBER { negative_timeout = $2; }
> > >  	| OPT_SYMLINK	{ symlnk = 1; }
> > >  	| OPT_STRICTEXPIRE { strictexpire = 1; }
> > > +	| OPT_SHARED	{ shared = 1; }
> > >  	| OPT_SLAVE	{ slave = 1; }
> > >  	| OPT_PRIVATE	{ private = 1; }
> > >  	| OPT_NOBIND	{ nobind = 1; }
> > > @@ -907,8 +910,10 @@ int master_parse_entry(const char *buffer,
> > > unsigned int default_timeout, unsigne
> > >  		entry->ap->flags |= MOUNT_FLAG_SYMLINK;
> > >  	if (strictexpire)
> > >  		entry->ap->flags |= MOUNT_FLAG_STRICTEXPIRE;
> > > -	if (slave)
> > > -		entry->ap->flags |= MOUNT_FLAG_SLAVE;
> > > +	/* Default is propagation slave */
> > > +	entry->ap->flags |= MOUNT_FLAG_SLAVE;
> > > +	if (shared)
> > > +		entry->ap->flags |= MOUNT_FLAG_SHARED;
> > >  	if (private)
> > >  		entry->ap->flags |= MOUNT_FLAG_PRIVATE;
> > 
> > If the user mention shared or private flag, you will end up
> > enabling both MOUNT_FLAG_SLAVE and MOUNT_FLAG_SHARED.
> > It would be better to put it in a if..else if..else sequence.
> > These are options are mutually exclusive.
> 
> Thanks for noticing this obvious blunder.
> I'll fix that up and send an update.

And the new variable, shared, initialization is missing too!

> 
> Ian


  reply	other threads:[~2019-10-30  6:05 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
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 [this message]
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=6422274be72dd4fe99978122553f991adbb5ec0c.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.