From: Ram Pai <linuxram@us.ibm.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
Al Viro <viro@ftp.linux.org.uk>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 12/18] shared mount handling: bind and rbind
Date: Wed, 09 Nov 2005 11:28:20 -0800 [thread overview]
Message-ID: <1131564500.5400.407.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.64.0511091054290.3247@g5.osdl.org>
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
next prev parent reply other threads:[~2005-11-09 19:28 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-08 2:01 [PATCH 12/18] shared mount handling: bind and rbind Al Viro
2005-11-08 14:11 ` Miklos Szeredi
2005-11-08 15:48 ` Ram Pai
2005-11-08 15:55 ` Miklos Szeredi
2005-11-09 18:44 ` Ram Pai
2005-11-09 18:59 ` Linus Torvalds
2005-11-09 19:26 ` Al Viro
2005-11-09 19:28 ` Ram Pai [this message]
2005-11-16 3:29 ` Rob Landley
2005-11-16 3:53 ` Linus Torvalds
2005-11-16 5:35 ` Al Boldi
2005-11-16 8:19 ` Miklos Szeredi
2005-11-16 9:10 ` Rob Landley
2005-11-16 10:14 ` Miklos Szeredi
2005-11-16 13:59 ` Shaya Potter
2005-11-16 16:35 ` Miklos Szeredi
2005-11-16 20:05 ` Al Boldi
2005-11-16 20:21 ` Shaya Potter
2005-11-16 8:47 ` Rob Landley
2005-11-16 8:41 ` Rob Landley
2005-11-16 16:18 ` Linus Torvalds
2005-11-09 10:54 ` Miklos Szeredi
2005-11-09 14:31 ` Al Viro
2005-11-09 15:22 ` Miklos Szeredi
2005-11-09 15:56 ` Al Viro
2005-11-09 16:33 ` Miklos Szeredi
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=1131564500.5400.407.camel@localhost \
--to=linuxram@us.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=torvalds@osdl.org \
--cc=viro@ftp.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;
as well as URLs for NNTP newsgroup(s).