Re: [PATCH 12/18] shared mount handling: bind and rbind

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2005-11-09 at 10:59, Linus Torvalds wrote:
> On Wed, 9 Nov 2005, Ram Pai wrote:
> >
> > And 'umount .' really doen't make sense. What does it mean? umount the 
> > current mount? or umount of the mount that is mounted on this dentry?
> 
> "umount <directory>" _absolutely_ makes sense, whether "directory" is "." 
> or something else. People do it all the time.

ok. so you say 'umount <dir>' means umount something mounted on top of
dir.  In that case, when I say 'umount /tmp' it has to unmount something
that is mounted on top of /tmp, but there cannot be anything mounted on
top of /tmp. In the first place I cannot reach this mount since it is
obscured by the mount on top. right?

eg:  m1 is the root mount
     m2 is the mount on top of tmp on the root mount
     m3 is the mount on top of tmp(root dentry) of m2

'umount /tmp' 
will mean umount something that is mounted on top of root dentry of m3.



> 
> Now, if it doesn't unmount the last thing mounted on top of ".", then 
> that's a misfeature. It might be a misfeature in the mount program (it 
> might scan /etc/mounts top-to-bottom rather than the other way), but the 
> kernel should also support it.
> 
> > no. I said application _should_not_ depend on it, because it is a
> > undefined semantics.
> 
> It's definitely neither unusual nor undefined. I do all my umounts by 
> directory (in fact, doing it by anything else really _is_ badly defined, 
> since a block device can be mounted in many places), and the only sane 
> semantics would be to peel off the last mount on that directory.
> 
> Now, that doesn't necessarily mean that "list_add_tail()" is wrong. But 
> if we add new mounts to the end, then umount remove them from the end too, 
> no?

Yes it does. it removes the mounts that receive propagation from the
tail.  Anything that has been asked to be unmounted explicitly will be
removed irrespective of where it is on the list, and always it is at the
head because lookup_mnt() always returns the one at the head.

RP
> 
> 		Linus

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux