public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ram Pai <linuxram@us.ibm.com>
To: Rob Landley <rob@landley.net>
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 16:01:23 -0800	[thread overview]
Message-ID: <1130803283.4773.40.camel@localhost> (raw)
In-Reply-To: <200510311727.27145.rob@landley.net>

On Mon, 2005-10-31 at 15:27, Rob Landley wrote:
> 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.

and having a "global view" is a debatable issue. What you are asking for
is a way for a process to be able to access all the mounts irrespective
of which namespace it belongs to. 

I think 'umount -a' semantics has to be refined and made as 'unmount all
the mounts belonging its namespace'. And if you agree with the
semantics, than unmouting whatever is found in /proc/mounts would
suffice.


> 
> 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?)  

yes all the mounts in the namespace will get cleaned up if no processes
have access to that namespace.

> 
> 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?)

Again as I said above, 'umount -a' has just to restrict itself to its
own namespace.

RP
> 
> It's a bit conceptually persnickety, so far...
> 
> Rob


  reply	other threads:[~2005-11-01  0:01 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
2005-11-01  0:01         ` Ram Pai [this message]
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=1130803283.4773.40.camel@localhost \
    --to=linuxram@us.ibm.com \
    --cc=greg@enjellic.com \
    --cc=leimy2k@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikew@google.com \
    --cc=rob@landley.net \
    /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