From: Andy Lutomirski <luto@amacapital.net>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>,
Andrey Wagin <avagin@gmail.com>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] umount.2: Correct the description of MNT_DETACH
Date: Mon, 29 Sep 2014 19:16:24 -0700 [thread overview]
Message-ID: <CALCETrUOeCrjAy---FM-8ovU1FD372ShgBeS5_1LUkgRWMQ4gQ@mail.gmail.com> (raw)
In-Reply-To: <87oatxzwex.fsf@x220.int.ebiederm.org>
On Mon, Sep 29, 2014 at 7:15 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Andy Lutomirski <luto@amacapital.net> writes:
>
>> On Mon, Sep 29, 2014 at 6:04 PM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>>>
>>> I recently realized that I had been reasoning improperly about what
>>> umount(MNT_DETACH) did based on an insufficient description in
>>> the umount.2 man page, that matched my intuition but not the
>>> implementation.
>>>
>>> When there are no submounts MNT_DETACH is essentially harmless to
>>> applications. Where there are submounts MNT_DETACH changes what
>>> is visible to applications using the detach directories.
>>>
>>> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>>> ---
>>> man2/umount.2 | 7 ++++---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/man2/umount.2 b/man2/umount.2
>>> index 5ff88152c738..aea39d8306fe 100644
>>> --- a/man2/umount.2
>>> +++ b/man2/umount.2
>>> @@ -66,9 +66,10 @@ This can cause data loss.
>>> (Only for NFS mounts.)
>>> .TP
>>> .BR MNT_DETACH " (since Linux 2.4.11)"
>>> -Perform a lazy unmount: make the mount point unavailable for
>>> -new accesses, and actually perform the unmount when the mount point
>>> -ceases to be busy.
>>> +Perform a lazy unmount: make the mount point unavailable for new
>>> +accesses, immediately disconnect the filesystem and all filesystems
>>> +mounted below it from each other and from the mount table, and
>>> +actually perform the unmount when the mount point ceases to be busy.
>>
>> Want to add something like:
>>
>> MNT_DETACH on a shared mount will propagate unmount events to its peer
>> group. That means that recursively bind mounting a shared mount and
>> then unmounting that recursive bind mount will unmount all submounts
>> of the original mount. This behavior can be avoided by remounting a
>> directory with MS_REC | MS_PRIVATE before unmounting it.
>
> Make that any unmount on a shared mount that will propogate unmount
> events to it's peer group.
I don't understand your proposed edit. Can you type it out explicitly?
--Andy
>
> Eric
>
--
Andy Lutomirski
AMA Capital Management, LLC
next prev parent reply other threads:[~2014-09-30 2:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-30 1:04 [PATCH] umount.2: Correct the description of MNT_DETACH Eric W. Biederman
2014-09-30 1:28 ` Andy Lutomirski
2014-09-30 2:15 ` Eric W. Biederman
2014-09-30 2:16 ` Andy Lutomirski [this message]
2014-10-28 13:43 ` Michael Kerrisk (man-pages)
2014-10-28 17:31 ` Eric W. Biederman
2014-10-28 17:33 ` [PATCH] umount.2: Document the effect of shared subtrees on umount Eric W. Biederman
2015-02-02 15:36 ` Michael Kerrisk (man-pages)
2015-02-02 15:34 ` [PATCH] umount.2: Correct the description of MNT_DETACH Michael Kerrisk (man-pages)
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=CALCETrUOeCrjAy---FM-8ovU1FD372ShgBeS5_1LUkgRWMQ4gQ@mail.gmail.com \
--to=luto@amacapital.net \
--cc=avagin@gmail.com \
--cc=ebiederm@xmission.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=viro@zeniv.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).