linux-fsdevel.vger.kernel.org archive mirror
 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 15:41:37 +0800	[thread overview]
Message-ID: <7f31f0c2bf214334a8f7e855044c88a50e006f05.camel@themaw.net> (raw)
In-Reply-To: <d163042ab8fffd975a6d460488f1539c5f619eaa.camel@themaw.net>

On Fri, 2019-09-27 at 15:26 +0800, Ian Kent wrote:
> On Fri, 2019-09-27 at 15:09 +0800, Ian Kent wrote:
> > On Fri, 2019-09-27 at 09:35 +0800, Ian Kent wrote:
> > > On Thu, 2019-09-26 at 14:52 -0500, Goldwyn Rodrigues wrote:
> > > > An access to automounted filesystem can deadlock if it is a
> > > > bind
> > > > mount on shared mounts. A user program should not deadlock the
> > > > kernel
> > > > while automount waits for propagation of the mount. This is
> > > > explained
> > > > at https://bugzilla.redhat.com/show_bug.cgi?id=1358887#c10
> > > > I am not sure completely blocking automount is the best
> > > > solution,
> > > > so please reply with what is the best course of action to do
> > > > in such a situation.
> > > > 
> > > > Propagation of dentry with DCACHE_NEED_AUTOMOUNT can lead to
> > > > propagation of mount points without automount maps and not
> > > > under
> > > > automount control. So, do not propagate them.
> > > 
> > > Yes, I'm not sure my comments about mount propagation in that
> > > bug are accurate.
> > > 
> > > This behaviour has crept into the kernel in reasonably recent
> > > times, maybe it's a bug or maybe mount propagation has been
> > > "fixed", not sure.
> > > 
> > > I think I'll need to come up with a more detailed description
> > > of what is being done for Al to be able to offer advice.
> > > 
> > > I'll get to that a bit later.
> > 
> > To duplicate this problem use an autofs indirect map
> > that uses bind mounts and has offsets:
> > 
> > test	/	:/exports \
> > 	/tmp	:/exports/tmp \
> > 	/lib	:/exports/lib
> > 
> > and add:
> > 
> > /bind	/etc/auto.exports
> > 
> > to /etc/auto.master.
> > 
> > Finally create the bind mount directories:
> > 
> > mkdir -p /exports/lib /exports/tmp
> > 
> > Then, on a broken kernel, eg. 4.13.9-300.fc27:
> > 
> > ls /bind/test
> > 
> > will result in:
> > 
> > /etc/auto.exports on /bind type autofs
> > (rw,relatime,fd=5,pgrp=2981,timeout=300,minproto=5,maxproto=5,indir
> > ec
> > t,pipe_ino=45485)
> > /dev/mapper/fedora_f27-root on /bind/test type ext4
> > (rw,relatime,seclabel,data=ordered)
> > /etc/auto.exports on /bind/test/lib type autofs
> > (rw,relatime,fd=5,pgrp=2981,timeout=300,minproto=5,maxproto=5,offse
> > t,
> > pipe_ino=45485)
> > /etc/auto.exports on /exports/lib type autofs
> > (rw,relatime,fd=5,pgrp=2981,timeout=300,minproto=5,maxproto=5,offse
> > t,
> > pipe_ino=45485)
> > /etc/auto.exports on /bind/test/tmp type autofs
> > (rw,relatime,fd=5,pgrp=2981,timeout=300,minproto=5,maxproto=5,offse
> > t,
> > pipe_ino=45485)
> > /etc/auto.exports on /exports/tmp type autofs
> > (rw,relatime,fd=5,pgrp=2981,timeout=300,minproto=5,maxproto=5,offse
> > t,
> > pipe_ino=45485)
> > 
> > these mount entries, not all of which have been mounted by autofs.
> > 
> > Whereas on a kernel that isn't broken, eg. 4.11.8-300.fc26, the
> > same
> > ls command will result in:
> > 
> > /etc/auto.exports on /bind type autofs
> > (rw,relatime,fd=6,pgrp=2920,timeout=300,minproto=5,maxproto=5,indir
> > ec
> > t,pipe_ino=42067)
> > /etc/auto.exports on /bind/test/lib type autofs
> > (rw,relatime,fd=6,pgrp=2920,timeout=300,minproto=5,maxproto=5,offse
> > t,
> > pipe_ino=42067)
> > /etc/auto.exports on /bind/test/tmp type autofs
> > (rw,relatime,fd=6,pgrp=2920,timeout=300,minproto=5,maxproto=5,offse
> > t,
> > pipe_ino=42067)
> > 
> > these mount entries, all of which have been mounted by autofs (and
> > are what's needed for these offset mount constructs).
> > 
> > If the /bind mount is made propagation slave or private at mount
> > by automount the problem doesn't happen and that is the workaround
> > I implemented in autofs.
> 
> Actually that's not quite right, there should be a bind mount at
> /bind/test as well but it's not present.
> 
> Although I expect this will happen with a rootless multi-mount
> as well, aka.
> 
> test \
>    /tmp	:/exports/tmp \
>    /lib	:/exports/lib
> 
> Leave it with me while I investigate further.

Ok, so this is actually what should have been produced on
4.11.8-300.fc26:

/etc/auto.exports on /bind type autofs (rw,relatime,fd=7,pgrp=1800,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=32018)
/dev/mapper/fedora_f26-root on /bind/test type ext4 (rw,relatime,seclabel,data=ordered)
/etc/auto.exports on /bind/test/lib type autofs (rw,relatime,fd=7,pgrp=1800,timeout=300,minproto=5,maxproto=5,offset,pipe_ino=32018)
/etc/auto.exports on /exports/lib type autofs (rw,relatime,fd=7,pgrp=1800,timeout=300,minproto=5,maxproto=5,offset,pipe_ino=32018)
/etc/auto.exports on /bind/test/tmp type autofs (rw,relatime,fd=7,pgrp=1800,timeout=300,minproto=5,maxproto=5,offset,pipe_ino=32018)
/etc/auto.exports on /exports/tmp type autofs (rw,relatime,fd=7,pgrp=1800,timeout=300,minproto=5,maxproto=5,offset,pipe_ino=32018)

which is also broken.

I'll need to check more kernels.

> 
> > 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.
> > > 
> > > >  	/*
> > > >  	 * we don't want to bother passing tons of arguments to
> > > >  	 * propagate_one(); everything is serialized by
> > > > namespace_sem,
> > > > 


  reply	other threads:[~2019-09-27  7:41 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 [this message]
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
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=7f31f0c2bf214334a8f7e855044c88a50e006f05.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).