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>
Subject: MNT_DETACH and mount namespace issue (was: Re: [PATCH] vfs: Fix RCU usage in __propagate_umount())
Date: Wed, 30 Jul 2014 22:46:31 +0200 [thread overview]
Message-ID: <53D959A7.5070702@nod.at> (raw)
In-Reply-To: <1406728756-32443-1-git-send-email-richard@sigma-star.at>
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.
Any ideas?
Thanks,
//richard
next prev parent reply other threads:[~2014-07-30 20:46 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 ` Richard Weinberger [this message]
2014-07-31 22:17 ` MNT_DETACH and mount namespace issue Richard Weinberger
2014-08-01 15:44 ` 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=53D959A7.5070702@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=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