From: Rob Landley <rob@landley.net>
To: Ram Pai <linuxram@us.ibm.com>
Cc: greg@enjellic.com, Mike Waychison <mikew@google.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
leimy2k@gmail.com
Subject: Re: /etc/mtab and per-process namespaces
Date: Mon, 31 Oct 2005 17:27:26 -0600 [thread overview]
Message-ID: <200510311727.27145.rob@landley.net> (raw)
In-Reply-To: <1130785899.4773.19.camel@localhost>
On Monday 31 October 2005 13:11, Ram Pai wrote:
> > The big thing I've never figured out how to do is make umount -a work in
> > the presence of multiple namespaces. (Should it just umount what it
> > sees? I don't know how to umount everything because I can't find
> > everything...)
>
> Yes you won't find everything, since some of them are in a different
> namespaces. Instead unmount whatever you see. Or use /proc/mounts
> to unmount whatever is there in its namespace.
But /proc/mounts is a symlink to self/mounts, and self is a symlink to $PID,
so after burrowing through the symlinks you wind up looking
at /proc/$PID/mounts.
My concern is that if I have init, as root, try to perform a umount -a, it
_still_ won't get the mounts belonging to child processes with a separate
namespace. There's no "global view" of mounts available anywhere.
On the other hand, if we fork a child process with its own namespace, the
child performs a private mount, and then we kill that child process, does
that hidden mount get umounted cleanly via refcounting? (Or does it leak?)
If killing the processes umounts their private mounts, all init has to do is
make sure all child processes are dead before doing a umount -a on what's
left. (Then, of course, there's FUSE. Does killing the FUSE helper prevent
the mount from being umounted?)
It's a bit conceptually persnickety, so far...
Rob
next prev parent reply other threads:[~2005-10-31 23:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-22 13:23 /etc/mtab and per-process namespaces Dr. Greg Wettstein
2005-10-29 0:06 ` Ram Pai
2005-10-29 10:16 ` Rob Landley
2005-10-31 19:11 ` Ram Pai
2005-10-31 23:27 ` Rob Landley [this message]
2005-11-01 0:01 ` Ram Pai
2005-11-01 7:36 ` Miklos Szeredi
2005-11-01 8:44 ` Rob Landley
[not found] <50rBX-76N-37@gated-at.bofh.it>
[not found] ` <50rBX-76N-35@gated-at.bofh.it>
2005-10-22 17:26 ` Bodo Eggert
[not found] <4TkbZ-6KJ-9@gated-at.bofh.it>
[not found] ` <4U0uy-33E-7@gated-at.bofh.it>
[not found] ` <4U0XK-3Gp-47@gated-at.bofh.it>
2005-10-04 21:20 ` Bodo Eggert
2005-10-05 0:14 ` Al Viro
-- strict thread matches above, loose matches on Subject: below --
2005-10-02 22:08 David Leimbach
2005-10-04 19:14 ` David Leimbach
2005-10-04 19:18 ` Christoph Hellwig
2005-10-04 19:49 ` Michael Tokarev
2005-10-04 19:52 ` David Leimbach
2005-10-04 19:43 ` Al Viro
2005-10-04 20:07 ` David Leimbach
2005-10-04 20:20 ` Al Viro
2005-10-05 16:29 ` Ram
2005-10-14 2:10 ` Mike Waychison
2005-10-17 0:47 ` Ian Kent
2005-10-20 3:53 ` Rob Landley
2005-10-20 3:42 ` Rob Landley
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=200510311727.27145.rob@landley.net \
--to=rob@landley.net \
--cc=greg@enjellic.com \
--cc=leimy2k@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=mikew@google.com \
/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