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 09:35:13 +0800 [thread overview]
Message-ID: <3468a81a09d13602c67007759593ddf450f8132c.camel@themaw.net> (raw)
In-Reply-To: <20190926195234.bipqpw5sbk5ojcna@fiona>
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.
>
> 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,
>
next prev parent reply other threads:[~2019-09-27 1:35 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 [this message]
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
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=3468a81a09d13602c67007759593ddf450f8132c.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).