From: Richard Weinberger <richard@nod.at>
To: linux-fsdevel@vger.kernel.org
Cc: viro@zeniv.linux.org.uk, hch@infradead.org,
paulmck@linux.vnet.ibm.com, jeffm@suse.com, sahne@0x90.at,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linuxram@us.ibm.com
Subject: Re: MNT_DETACH and mount namespace issue
Date: Fri, 01 Aug 2014 00:17:13 +0200 [thread overview]
Message-ID: <53DAC069.7070606@nod.at> (raw)
In-Reply-To: <53D959A7.5070702@nod.at>
Am 30.07.2014 22:46, schrieb Richard Weinberger:
> Am 30.07.2014 15:59, schrieb Richard Weinberger:
>> If we use the plain list_empty() we might not see the
>> hlist_del_init_rcu() and therefore miss one member of the
>> list.
>>
>> It fixes the following issue:
>> $ unshare -m /usr/bin/sleep 10000 &
>> $ mkdir -p foo/proc
>> $ mount -t proc none foo/proc
>> $ mount -t binfmt_misc none foo/proc/sys/fs/binfmt_misc
>> $ umount -l foo/proc
>> $ rmdir foo/proc
>> rmdir: failed to remove ‘foo/proc’: Device or resource busy
>
> Although my fix was wrong, the issue is real, it seems to exist for a very long
> time. Just was able to reproduce it on 2.6.32.
> Please note that you need a shared root subtree to trigger the issue.
> i.e. mount --shared /
> Maybe this is why nobody noticed it so far as only systemd distros
> have the root subtree shared by default.
>
> I hit the issue on openSUSE 13.1 where an application creates a chroot environment
> and then lazy umounts /proc.
> It happened on very few machines. An analysis showed that only boxes with an OpenVPN tunnel
> were affected. This did not make any sense until I discovered that the OpenVPN systemd
> service file has set "PrivateTmp=true". This setting creates
> a mount namespace for the said service...
>
> In __propagate_umount() the following piece of code is interesting:
>
> /*
> * umount the child only if the child has no
> * other children
> */
> if (child && list_empty(&child->mnt_mounts)) {
> hlist_del_init_rcu(&child->mnt_hash);
> hlist_add_before_rcu(&child->mnt_hash, &mnt->mnt_hash);
> }
>
> child->mnt_mounts is non-empty for the "proc" although the "binfmt_misc"
> subtree was removed.
> I'm not sure whether this is only one more symptom or the main culprit.
CC'ing Ram Pai.
Ram, you are the author of the said code. Can you please explain why we need that
list_empty() check?
To my (limited) understanding of VFS, the following change should be fine to fix the issue:
diff --git a/fs/pnode.c b/fs/pnode.c
index 302bf22..627b35f 100644
--- a/fs/pnode.c
+++ b/fs/pnode.c
@@ -376,11 +376,7 @@ static void __propagate_umount(struct mount *mnt)
struct mount *child = __lookup_mnt_last(&m->mnt,
mnt->mnt_mountpoint);
- /*
- * umount the child only if the child has no
- * other children
- */
- if (child && list_empty(&child->mnt_mounts)) {
+ if (child) {
hlist_del_init_rcu(&child->mnt_hash);
hlist_add_before_rcu(&child->mnt_hash, &mnt->mnt_hash);
}
Thanks,
//richard
next prev parent reply other threads:[~2014-07-31 22:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-30 13:59 [PATCH] vfs: Fix RCU usage in __propagate_umount() Richard Weinberger
2014-07-30 14:20 ` Richard Weinberger
2014-07-30 18:39 ` Paul E. McKenney
2014-07-30 20:46 ` MNT_DETACH and mount namespace issue (was: Re: [PATCH] vfs: Fix RCU usage in __propagate_umount()) Richard Weinberger
2014-07-31 22:17 ` Richard Weinberger [this message]
2014-08-01 15:44 ` MNT_DETACH and mount namespace issue Ram Pai
2014-08-01 19:20 ` Richard Weinberger
2014-08-01 22:09 ` Eric W. Biederman
2014-08-04 8:40 ` Richard Weinberger
2014-08-04 16:46 ` Eric W. Biederman
2014-08-04 21:19 ` Richard Weinberger
2014-08-04 22:10 ` Ram Pai
2014-08-04 22:16 ` Richard Weinberger
2014-08-04 22:59 ` Eric W. Biederman
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=53DAC069.7070606@nod.at \
--to=richard@nod.at \
--cc=hch@infradead.org \
--cc=jeffm@suse.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=sahne@0x90.at \
--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).