Re: /etc/mtab and per-process namespaces

[Ram Pai]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/