From: Linus Torvalds <torvalds@osdl.org>
To: Ram Pai <linuxram@us.ibm.com>
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, 9 Nov 2005 10:59:47 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0511091054290.3247@g5.osdl.org> (raw)
In-Reply-To: <1131561849.5400.384.camel@localhost>
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.
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?
Linus
next prev parent reply other threads:[~2005-11-09 19:00 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 [this message]
2005-11-09 19:26 ` Al Viro
2005-11-09 19:28 ` Ram Pai
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=Pine.LNX.4.64.0511091054290.3247@g5.osdl.org \
--to=torvalds@osdl.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=miklos@szeredi.hu \
--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).