From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
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: Tue, 28 Oct 2014 14:43:25 +0100 [thread overview]
Message-ID: <544F9D7D.40301@gmail.com> (raw)
In-Reply-To: <CALCETrUOeCrjAy---FM-8ovU1FD372ShgBeS5_1LUkgRWMQ4gQ@mail.gmail.com>
Hi Eric,
I'm still hoping for a revised patch from you in the light
of Andy's comments and question.
Thanks,
Michael
On 09/30/2014 04:16 AM, Andy Lutomirski wrote:
> 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
>>
>
>
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
next prev parent reply other threads:[~2014-10-28 13:43 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
2014-10-28 13:43 ` Michael Kerrisk (man-pages) [this message]
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=544F9D7D.40301@gmail.com \
--to=mtk.manpages@gmail.com \
--cc=avagin@gmail.com \
--cc=ebiederm@xmission.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.