* Improving documentation of parent-ID field in /proc/PID/mountinfo
@ 2017-11-13 6:02 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 12+ messages in thread
From: Michael Kerrisk (man-pages) @ 2017-11-13 6:02 UTC (permalink / raw)
To: Ram Pai
Cc: lkml, linux-man, Alexander Eder, Miklos Szeredi, Michael Kerrisk,
linux-fsdevel
Hello Ram,
Long ago (2.6.29) you added the /proc/PID/mountinfo file and
associated documentation in Documentation/filesystems/proc.txt. Later,
I pasted much of that documentation into the proc(5) manual page.
That documentation says of the second field in the file:
[[
This file contains lines of the form:
36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue
(1)(2)(3) (4) (5) (6) (7) (8) (9) (10) (11)
(1) mount ID: unique identifier of the mount (may be reused after umount)
(2) parent ID: ID of parent (or of self for the top of the mount tree)
...
]]
The last piece of the description of field (2) doesn't seem to be
correct, or is at least rather unclear. I take this to be saying that
that for the root mount point, /, field (2) will have the same value
as field (1). I never actually looked at this detail closely, but
Alexander pointed out that this is obviously not so, as one can
immediately verify:
$ grep '/ / ' /proc/$$/mountinfo
65 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,seclabel,data=order
I dug around in the kernel source for a bit. I do not have an exact
handle on the details, but I can see roughly what is going on.
Internally, there seems to be one ("hidden") mount ID reserved to each
mount namespace, and that ID is the parent of the root mount point.
Looking through the (4.14) kernel source, mount IDs are allocated by
mnt_alloc_id() (in fs/namespace.c), which is in turn called by
alloc_vfsmnt() which is in turn called by clone_mnt().
A new mount namespace is created by the kernel function copy_mnt_ns()
(in fs/namespace.c, called by create_new_namespaces() in
kernel/nsproxy.c). The copy_mnt_ns() function calls copy_tree() (in
fs/namespace.c), and copy_tree() calls clone_mnt() in *two* places.
The first of these is the call that creates the "hidden" mount ID that
becomes the parent of the root mount point. (I verified this by
instrumenting the kernel with a few printk() calls to display the
IDs.) The second place where copy_tree() calls clone_mnt() is in a
loop that replicates each of the mount points (including the root
mount point) in the source mount namespace.
With these details in mind, I propose to patch the man page to read as
below. Perhaps you have some corrections or improvements to suggest
for this text?
[[
(2) parent ID: the ID of the parent mount. For the root
mount point, the ID shown here is a hidden mount ID
associated with the mount namespace. That ID is dis‐
tinct from any of the IDs shown in field (1) of the
records shown in the mountinfo file, and does not
appear in field (1) in the mountinfo file in any other
mount namespace. (In the initial mount namespace,
this hidden ID has the value 0.)
]]
With best regards,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Improving documentation of parent-ID field in /proc/PID/mountinfo
@ 2017-11-13 6:02 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 12+ messages in thread
From: Michael Kerrisk (man-pages) @ 2017-11-13 6:02 UTC (permalink / raw)
To: Ram Pai
Cc: lkml, linux-man, Alexander Eder, Miklos Szeredi, Michael Kerrisk,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Hello Ram,
Long ago (2.6.29) you added the /proc/PID/mountinfo file and
associated documentation in Documentation/filesystems/proc.txt. Later,
I pasted much of that documentation into the proc(5) manual page.
That documentation says of the second field in the file:
[[
This file contains lines of the form:
36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue
(1)(2)(3) (4) (5) (6) (7) (8) (9) (10) (11)
(1) mount ID: unique identifier of the mount (may be reused after umount)
(2) parent ID: ID of parent (or of self for the top of the mount tree)
...
]]
The last piece of the description of field (2) doesn't seem to be
correct, or is at least rather unclear. I take this to be saying that
that for the root mount point, /, field (2) will have the same value
as field (1). I never actually looked at this detail closely, but
Alexander pointed out that this is obviously not so, as one can
immediately verify:
$ grep '/ / ' /proc/$$/mountinfo
65 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,seclabel,data=order
I dug around in the kernel source for a bit. I do not have an exact
handle on the details, but I can see roughly what is going on.
Internally, there seems to be one ("hidden") mount ID reserved to each
mount namespace, and that ID is the parent of the root mount point.
Looking through the (4.14) kernel source, mount IDs are allocated by
mnt_alloc_id() (in fs/namespace.c), which is in turn called by
alloc_vfsmnt() which is in turn called by clone_mnt().
A new mount namespace is created by the kernel function copy_mnt_ns()
(in fs/namespace.c, called by create_new_namespaces() in
kernel/nsproxy.c). The copy_mnt_ns() function calls copy_tree() (in
fs/namespace.c), and copy_tree() calls clone_mnt() in *two* places.
The first of these is the call that creates the "hidden" mount ID that
becomes the parent of the root mount point. (I verified this by
instrumenting the kernel with a few printk() calls to display the
IDs.) The second place where copy_tree() calls clone_mnt() is in a
loop that replicates each of the mount points (including the root
mount point) in the source mount namespace.
With these details in mind, I propose to patch the man page to read as
below. Perhaps you have some corrections or improvements to suggest
for this text?
[[
(2) parent ID: the ID of the parent mount. For the root
mount point, the ID shown here is a hidden mount ID
associated with the mount namespace. That ID is dis‐
tinct from any of the IDs shown in field (1) of the
records shown in the mountinfo file, and does not
appear in field (1) in the mountinfo file in any other
mount namespace. (In the initial mount namespace,
this hidden ID has the value 0.)
]]
With best regards,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Improving documentation of parent-ID field in /proc/PID/mountinfo
2017-11-13 6:02 ` Michael Kerrisk (man-pages)
(?)
@ 2017-11-13 7:55 ` Ram Pai
2017-11-13 8:11 ` Miklos Szeredi
-1 siblings, 1 reply; 12+ messages in thread
From: Ram Pai @ 2017-11-13 7:55 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: lkml, linux-man, Alexander Eder, Miklos Szeredi, linux-fsdevel
On Mon, Nov 13, 2017 at 07:02:21AM +0100, Michael Kerrisk (man-pages) wrote:
> Hello Ram,
>
> Long ago (2.6.29) you added the /proc/PID/mountinfo file and
> associated documentation in Documentation/filesystems/proc.txt. Later,
> I pasted much of that documentation into the proc(5) manual page.
>
> That documentation says of the second field in the file:
>
> [[
> This file contains lines of the form:
>
> 36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue
> (1)(2)(3) (4) (5) (6) (7) (8) (9) (10) (11)
>
> (1) mount ID: unique identifier of the mount (may be reused after umount)
> (2) parent ID: ID of parent (or of self for the top of the mount tree)
> ...
> ]]
>
> The last piece of the description of field (2) doesn't seem to be
> correct, or is at least rather unclear. I take this to be saying that
> that for the root mount point, /, field (2) will have the same value
> as field (1). I never actually looked at this detail closely, but
> Alexander pointed out that this is obviously not so, as one can
> immediately verify:
>
> $ grep '/ / ' /proc/$$/mountinfo
> 65 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,seclabel,data=order
>
> I dug around in the kernel source for a bit. I do not have an exact
> handle on the details, but I can see roughly what is going on.
> Internally, there seems to be one ("hidden") mount ID reserved to each
> mount namespace, and that ID is the parent of the root mount point.
>
> Looking through the (4.14) kernel source, mount IDs are allocated by
> mnt_alloc_id() (in fs/namespace.c), which is in turn called by
> alloc_vfsmnt() which is in turn called by clone_mnt().
>
> A new mount namespace is created by the kernel function copy_mnt_ns()
> (in fs/namespace.c, called by create_new_namespaces() in
> kernel/nsproxy.c). The copy_mnt_ns() function calls copy_tree() (in
> fs/namespace.c), and copy_tree() calls clone_mnt() in *two* places.
> The first of these is the call that creates the "hidden" mount ID that
> becomes the parent of the root mount point. (I verified this by
> instrumenting the kernel with a few printk() calls to display the
> IDs.) The second place where copy_tree() calls clone_mnt() is in a
> loop that replicates each of the mount points (including the root
> mount point) in the source mount namespace.
We used to report that mount, ones upon a time. Something has changed
the behavior since then and its not reported any more, thus making it
hidden.
>
> With these details in mind, I propose to patch the man page to read as
> below. Perhaps you have some corrections or improvements to suggest
> for this text?
>
> [[
> (2) parent ID: the ID of the parent mount. For the root
> mount point, the ID shown here is a hidden mount ID
> associated with the mount namespace. That ID is dis‐
> tinct from any of the IDs shown in field (1) of the
> records shown in the mountinfo file, and does not
> appear in field (1) in the mountinfo file in any other
> mount namespace. (In the initial mount namespace,
> this hidden ID has the value 0.)
It captures the current semantics correctly.
RP
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Improving documentation of parent-ID field in /proc/PID/mountinfo
2017-11-13 7:55 ` Ram Pai
@ 2017-11-13 8:11 ` Miklos Szeredi
2017-11-14 7:08 ` Michael Kerrisk (man-pages)
0 siblings, 1 reply; 12+ messages in thread
From: Miklos Szeredi @ 2017-11-13 8:11 UTC (permalink / raw)
To: Ram Pai
Cc: Michael Kerrisk (man-pages),
lkml, linux-man, Alexander Eder, linux-fsdevel
On Mon, Nov 13, 2017 at 8:55 AM, Ram Pai <linuxram@us.ibm.com> wrote:
> On Mon, Nov 13, 2017 at 07:02:21AM +0100, Michael Kerrisk (man-pages) wrote:
>> Hello Ram,
>>
>> Long ago (2.6.29) you added the /proc/PID/mountinfo file and
>> associated documentation in Documentation/filesystems/proc.txt. Later,
>> I pasted much of that documentation into the proc(5) manual page.
>>
>> That documentation says of the second field in the file:
>>
>> [[
>> This file contains lines of the form:
>>
>> 36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue
>> (1)(2)(3) (4) (5) (6) (7) (8) (9) (10) (11)
>>
>> (1) mount ID: unique identifier of the mount (may be reused after umount)
>> (2) parent ID: ID of parent (or of self for the top of the mount tree)
>> ...
>> ]]
>>
>> The last piece of the description of field (2) doesn't seem to be
>> correct, or is at least rather unclear. I take this to be saying that
>> that for the root mount point, /, field (2) will have the same value
>> as field (1). I never actually looked at this detail closely, but
>> Alexander pointed out that this is obviously not so, as one can
>> immediately verify:
>>
>> $ grep '/ / ' /proc/$$/mountinfo
>> 65 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,seclabel,data=order
>>
>> I dug around in the kernel source for a bit. I do not have an exact
>> handle on the details, but I can see roughly what is going on.
>> Internally, there seems to be one ("hidden") mount ID reserved to each
>> mount namespace, and that ID is the parent of the root mount point.
>>
>> Looking through the (4.14) kernel source, mount IDs are allocated by
>> mnt_alloc_id() (in fs/namespace.c), which is in turn called by
>> alloc_vfsmnt() which is in turn called by clone_mnt().
>>
>> A new mount namespace is created by the kernel function copy_mnt_ns()
>> (in fs/namespace.c, called by create_new_namespaces() in
>> kernel/nsproxy.c). The copy_mnt_ns() function calls copy_tree() (in
>> fs/namespace.c), and copy_tree() calls clone_mnt() in *two* places.
>> The first of these is the call that creates the "hidden" mount ID that
>> becomes the parent of the root mount point. (I verified this by
>> instrumenting the kernel with a few printk() calls to display the
>> IDs.) The second place where copy_tree() calls clone_mnt() is in a
>> loop that replicates each of the mount points (including the root
>> mount point) in the source mount namespace.
>
> We used to report that mount, ones upon a time. Something has changed
> the behavior since then and its not reported any more, thus making it
> hidden.
The hidden one is the initramfs, I believe. That's the root of the
mount namespace, and the when a namespace is cloned, the tree is
copied from the namespace root.
It is "hidden" because no process has its root there. Note the
difference between namespace root and process root: the first is the
real root of the mount tree and is unchangeable, the second is
pointing to some place in a mount tree and can be changed (chroot).
So there's nothing special in this rootfs, it is just hidden because
it's not the root of any task.
The description of field (2) is correct, it just does not make it
clear what it means by "root".
Thanks,
Miklos
>
>>
>> With these details in mind, I propose to patch the man page to read as
>> below. Perhaps you have some corrections or improvements to suggest
>> for this text?
>>
>> [[
>> (2) parent ID: the ID of the parent mount. For the root
>> mount point, the ID shown here is a hidden mount ID
>> associated with the mount namespace. That ID is dis‐
>> tinct from any of the IDs shown in field (1) of the
>> records shown in the mountinfo file, and does not
>> appear in field (1) in the mountinfo file in any other
>> mount namespace. (In the initial mount namespace,
>> this hidden ID has the value 0.)
>
> It captures the current semantics correctly.
>
> RP
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Improving documentation of parent-ID field in /proc/PID/mountinfo
@ 2017-11-14 7:08 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 12+ messages in thread
From: Michael Kerrisk (man-pages) @ 2017-11-14 7:08 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: Ram Pai, lkml, linux-man, Alexander Eder, linux-fsdevel
Hi Miklos, Ram
Thanks for your comments. A question below.
On 13 November 2017 at 09:11, Miklos Szeredi <mszeredi@redhat.com> wrote:
> On Mon, Nov 13, 2017 at 8:55 AM, Ram Pai <linuxram@us.ibm.com> wrote:
>> On Mon, Nov 13, 2017 at 07:02:21AM +0100, Michael Kerrisk (man-pages) wrote:
>>> Hello Ram,
>>>
>>> Long ago (2.6.29) you added the /proc/PID/mountinfo file and
>>> associated documentation in Documentation/filesystems/proc.txt. Later,
>>> I pasted much of that documentation into the proc(5) manual page.
>>>
>>> That documentation says of the second field in the file:
>>>
>>> [[
>>> This file contains lines of the form:
>>>
>>> 36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue
>>> (1)(2)(3) (4) (5) (6) (7) (8) (9) (10) (11)
>>>
>>> (1) mount ID: unique identifier of the mount (may be reused after umount)
>>> (2) parent ID: ID of parent (or of self for the top of the mount tree)
>>> ...
>>> ]]
>>>
>>> The last piece of the description of field (2) doesn't seem to be
>>> correct, or is at least rather unclear. I take this to be saying that
>>> that for the root mount point, /, field (2) will have the same value
>>> as field (1). I never actually looked at this detail closely, but
>>> Alexander pointed out that this is obviously not so, as one can
>>> immediately verify:
>>>
>>> $ grep '/ / ' /proc/$$/mountinfo
>>> 65 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,seclabel,data=order
>>>
>>> I dug around in the kernel source for a bit. I do not have an exact
>>> handle on the details, but I can see roughly what is going on.
>>> Internally, there seems to be one ("hidden") mount ID reserved to each
>>> mount namespace, and that ID is the parent of the root mount point.
>>>
>>> Looking through the (4.14) kernel source, mount IDs are allocated by
>>> mnt_alloc_id() (in fs/namespace.c), which is in turn called by
>>> alloc_vfsmnt() which is in turn called by clone_mnt().
>>>
>>> A new mount namespace is created by the kernel function copy_mnt_ns()
>>> (in fs/namespace.c, called by create_new_namespaces() in
>>> kernel/nsproxy.c). The copy_mnt_ns() function calls copy_tree() (in
>>> fs/namespace.c), and copy_tree() calls clone_mnt() in *two* places.
>>> The first of these is the call that creates the "hidden" mount ID that
>>> becomes the parent of the root mount point. (I verified this by
>>> instrumenting the kernel with a few printk() calls to display the
>>> IDs.) The second place where copy_tree() calls clone_mnt() is in a
>>> loop that replicates each of the mount points (including the root
>>> mount point) in the source mount namespace.
>>
>> We used to report that mount, ones upon a time. Something has changed
>> the behavior since then and its not reported any more, thus making it
>> hidden.
>
> The hidden one is the initramfs, I believe. That's the root of the
> mount namespace, and the when a namespace is cloned, the tree is
> copied from the namespace root.
>
> It is "hidden" because no process has its root there. Note the
> difference between namespace root and process root: the first is the
> real root of the mount tree and is unchangeable, the second is
> pointing to some place in a mount tree and can be changed (chroot).
>
> So there's nothing special in this rootfs, it is just hidden because
> it's not the root of any task.
>
> The description of field (2) is correct, it just does not make it
> clear what it means by "root".
Sorry -- do you mean the old description is correct, or my new
description (below)?
Cheers,
Michael
> Thanks,
> Miklos
>
>>
>>>
>>> With these details in mind, I propose to patch the man page to read as
>>> below. Perhaps you have some corrections or improvements to suggest
>>> for this text?
>>>
>>> [[
>>> (2) parent ID: the ID of the parent mount. For the root
>>> mount point, the ID shown here is a hidden mount ID
>>> associated with the mount namespace. That ID is dis‐
>>> tinct from any of the IDs shown in field (1) of the
>>> records shown in the mountinfo file, and does not
>>> appear in field (1) in the mountinfo file in any other
>>> mount namespace. (In the initial mount namespace,
>>> this hidden ID has the value 0.)
>>
>> It captures the current semantics correctly.
>>
>> RP
>>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Improving documentation of parent-ID field in /proc/PID/mountinfo
@ 2017-11-14 7:08 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 12+ messages in thread
From: Michael Kerrisk (man-pages) @ 2017-11-14 7:08 UTC (permalink / raw)
To: Miklos Szeredi
Cc: Ram Pai, lkml, linux-man, Alexander Eder,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Hi Miklos, Ram
Thanks for your comments. A question below.
On 13 November 2017 at 09:11, Miklos Szeredi <mszeredi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Mon, Nov 13, 2017 at 8:55 AM, Ram Pai <linuxram-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
>> On Mon, Nov 13, 2017 at 07:02:21AM +0100, Michael Kerrisk (man-pages) wrote:
>>> Hello Ram,
>>>
>>> Long ago (2.6.29) you added the /proc/PID/mountinfo file and
>>> associated documentation in Documentation/filesystems/proc.txt. Later,
>>> I pasted much of that documentation into the proc(5) manual page.
>>>
>>> That documentation says of the second field in the file:
>>>
>>> [[
>>> This file contains lines of the form:
>>>
>>> 36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue
>>> (1)(2)(3) (4) (5) (6) (7) (8) (9) (10) (11)
>>>
>>> (1) mount ID: unique identifier of the mount (may be reused after umount)
>>> (2) parent ID: ID of parent (or of self for the top of the mount tree)
>>> ...
>>> ]]
>>>
>>> The last piece of the description of field (2) doesn't seem to be
>>> correct, or is at least rather unclear. I take this to be saying that
>>> that for the root mount point, /, field (2) will have the same value
>>> as field (1). I never actually looked at this detail closely, but
>>> Alexander pointed out that this is obviously not so, as one can
>>> immediately verify:
>>>
>>> $ grep '/ / ' /proc/$$/mountinfo
>>> 65 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,seclabel,data=order
>>>
>>> I dug around in the kernel source for a bit. I do not have an exact
>>> handle on the details, but I can see roughly what is going on.
>>> Internally, there seems to be one ("hidden") mount ID reserved to each
>>> mount namespace, and that ID is the parent of the root mount point.
>>>
>>> Looking through the (4.14) kernel source, mount IDs are allocated by
>>> mnt_alloc_id() (in fs/namespace.c), which is in turn called by
>>> alloc_vfsmnt() which is in turn called by clone_mnt().
>>>
>>> A new mount namespace is created by the kernel function copy_mnt_ns()
>>> (in fs/namespace.c, called by create_new_namespaces() in
>>> kernel/nsproxy.c). The copy_mnt_ns() function calls copy_tree() (in
>>> fs/namespace.c), and copy_tree() calls clone_mnt() in *two* places.
>>> The first of these is the call that creates the "hidden" mount ID that
>>> becomes the parent of the root mount point. (I verified this by
>>> instrumenting the kernel with a few printk() calls to display the
>>> IDs.) The second place where copy_tree() calls clone_mnt() is in a
>>> loop that replicates each of the mount points (including the root
>>> mount point) in the source mount namespace.
>>
>> We used to report that mount, ones upon a time. Something has changed
>> the behavior since then and its not reported any more, thus making it
>> hidden.
>
> The hidden one is the initramfs, I believe. That's the root of the
> mount namespace, and the when a namespace is cloned, the tree is
> copied from the namespace root.
>
> It is "hidden" because no process has its root there. Note the
> difference between namespace root and process root: the first is the
> real root of the mount tree and is unchangeable, the second is
> pointing to some place in a mount tree and can be changed (chroot).
>
> So there's nothing special in this rootfs, it is just hidden because
> it's not the root of any task.
>
> The description of field (2) is correct, it just does not make it
> clear what it means by "root".
Sorry -- do you mean the old description is correct, or my new
description (below)?
Cheers,
Michael
> Thanks,
> Miklos
>
>>
>>>
>>> With these details in mind, I propose to patch the man page to read as
>>> below. Perhaps you have some corrections or improvements to suggest
>>> for this text?
>>>
>>> [[
>>> (2) parent ID: the ID of the parent mount. For the root
>>> mount point, the ID shown here is a hidden mount ID
>>> associated with the mount namespace. That ID is dis‐
>>> tinct from any of the IDs shown in field (1) of the
>>> records shown in the mountinfo file, and does not
>>> appear in field (1) in the mountinfo file in any other
>>> mount namespace. (In the initial mount namespace,
>>> this hidden ID has the value 0.)
>>
>> It captures the current semantics correctly.
>>
>> RP
>>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Improving documentation of parent-ID field in /proc/PID/mountinfo
@ 2017-11-14 16:16 ` Miklos Szeredi
0 siblings, 0 replies; 12+ messages in thread
From: Miklos Szeredi @ 2017-11-14 16:16 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: Ram Pai, lkml, linux-man, Alexander Eder, linux-fsdevel
On Tue, Nov 14, 2017 at 8:08 AM, Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
> Hi Miklos, Ram
>
> Thanks for your comments. A question below.
>
> On 13 November 2017 at 09:11, Miklos Szeredi <mszeredi@redhat.com> wrote:
>> On Mon, Nov 13, 2017 at 8:55 AM, Ram Pai <linuxram@us.ibm.com> wrote:
>>> On Mon, Nov 13, 2017 at 07:02:21AM +0100, Michael Kerrisk (man-pages) wrote:
>>>> Hello Ram,
>>>>
>>>> Long ago (2.6.29) you added the /proc/PID/mountinfo file and
>>>> associated documentation in Documentation/filesystems/proc.txt. Later,
>>>> I pasted much of that documentation into the proc(5) manual page.
>>>>
>>>> That documentation says of the second field in the file:
>>>>
>>>> [[
>>>> This file contains lines of the form:
>>>>
>>>> 36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue
>>>> (1)(2)(3) (4) (5) (6) (7) (8) (9) (10) (11)
>>>>
>>>> (1) mount ID: unique identifier of the mount (may be reused after umount)
>>>> (2) parent ID: ID of parent (or of self for the top of the mount tree)
>>>> ...
>>>> ]]
>>>>
>>>> The last piece of the description of field (2) doesn't seem to be
>>>> correct, or is at least rather unclear. I take this to be saying that
>>>> that for the root mount point, /, field (2) will have the same value
>>>> as field (1). I never actually looked at this detail closely, but
>>>> Alexander pointed out that this is obviously not so, as one can
>>>> immediately verify:
>>>>
>>>> $ grep '/ / ' /proc/$$/mountinfo
>>>> 65 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,seclabel,data=order
>>>>
>>>> I dug around in the kernel source for a bit. I do not have an exact
>>>> handle on the details, but I can see roughly what is going on.
>>>> Internally, there seems to be one ("hidden") mount ID reserved to each
>>>> mount namespace, and that ID is the parent of the root mount point.
>>>>
>>>> Looking through the (4.14) kernel source, mount IDs are allocated by
>>>> mnt_alloc_id() (in fs/namespace.c), which is in turn called by
>>>> alloc_vfsmnt() which is in turn called by clone_mnt().
>>>>
>>>> A new mount namespace is created by the kernel function copy_mnt_ns()
>>>> (in fs/namespace.c, called by create_new_namespaces() in
>>>> kernel/nsproxy.c). The copy_mnt_ns() function calls copy_tree() (in
>>>> fs/namespace.c), and copy_tree() calls clone_mnt() in *two* places.
>>>> The first of these is the call that creates the "hidden" mount ID that
>>>> becomes the parent of the root mount point. (I verified this by
>>>> instrumenting the kernel with a few printk() calls to display the
>>>> IDs.) The second place where copy_tree() calls clone_mnt() is in a
>>>> loop that replicates each of the mount points (including the root
>>>> mount point) in the source mount namespace.
>>>
>>> We used to report that mount, ones upon a time. Something has changed
>>> the behavior since then and its not reported any more, thus making it
>>> hidden.
>>
>> The hidden one is the initramfs, I believe. That's the root of the
>> mount namespace, and the when a namespace is cloned, the tree is
>> copied from the namespace root.
>>
>> It is "hidden" because no process has its root there. Note the
>> difference between namespace root and process root: the first is the
>> real root of the mount tree and is unchangeable, the second is
>> pointing to some place in a mount tree and can be changed (chroot).
>>
>> So there's nothing special in this rootfs, it is just hidden because
>> it's not the root of any task.
>>
>> The description of field (2) is correct, it just does not make it
>> clear what it means by "root".
>
> Sorry -- do you mean the old description is correct, or my new
> description (below)?
Well, both are correct, yours just describes the same thing at the
higher level. But I think rootfs is an implementation detail, so is
the fact that it gets a zero mount ID, so I think the original
description better captures the essence of the interface. Except it
needs to clarify what "top of the mount tree" means. It doesn't mean
current process's root, rather it means the root of the mount tree in
the current mount namespace.
Thanks,
Miklos
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Improving documentation of parent-ID field in /proc/PID/mountinfo
@ 2017-11-14 16:16 ` Miklos Szeredi
0 siblings, 0 replies; 12+ messages in thread
From: Miklos Szeredi @ 2017-11-14 16:16 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: Ram Pai, lkml, linux-man, Alexander Eder,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
On Tue, Nov 14, 2017 at 8:08 AM, Michael Kerrisk (man-pages)
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Miklos, Ram
>
> Thanks for your comments. A question below.
>
> On 13 November 2017 at 09:11, Miklos Szeredi <mszeredi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> On Mon, Nov 13, 2017 at 8:55 AM, Ram Pai <linuxram-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
>>> On Mon, Nov 13, 2017 at 07:02:21AM +0100, Michael Kerrisk (man-pages) wrote:
>>>> Hello Ram,
>>>>
>>>> Long ago (2.6.29) you added the /proc/PID/mountinfo file and
>>>> associated documentation in Documentation/filesystems/proc.txt. Later,
>>>> I pasted much of that documentation into the proc(5) manual page.
>>>>
>>>> That documentation says of the second field in the file:
>>>>
>>>> [[
>>>> This file contains lines of the form:
>>>>
>>>> 36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue
>>>> (1)(2)(3) (4) (5) (6) (7) (8) (9) (10) (11)
>>>>
>>>> (1) mount ID: unique identifier of the mount (may be reused after umount)
>>>> (2) parent ID: ID of parent (or of self for the top of the mount tree)
>>>> ...
>>>> ]]
>>>>
>>>> The last piece of the description of field (2) doesn't seem to be
>>>> correct, or is at least rather unclear. I take this to be saying that
>>>> that for the root mount point, /, field (2) will have the same value
>>>> as field (1). I never actually looked at this detail closely, but
>>>> Alexander pointed out that this is obviously not so, as one can
>>>> immediately verify:
>>>>
>>>> $ grep '/ / ' /proc/$$/mountinfo
>>>> 65 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,seclabel,data=order
>>>>
>>>> I dug around in the kernel source for a bit. I do not have an exact
>>>> handle on the details, but I can see roughly what is going on.
>>>> Internally, there seems to be one ("hidden") mount ID reserved to each
>>>> mount namespace, and that ID is the parent of the root mount point.
>>>>
>>>> Looking through the (4.14) kernel source, mount IDs are allocated by
>>>> mnt_alloc_id() (in fs/namespace.c), which is in turn called by
>>>> alloc_vfsmnt() which is in turn called by clone_mnt().
>>>>
>>>> A new mount namespace is created by the kernel function copy_mnt_ns()
>>>> (in fs/namespace.c, called by create_new_namespaces() in
>>>> kernel/nsproxy.c). The copy_mnt_ns() function calls copy_tree() (in
>>>> fs/namespace.c), and copy_tree() calls clone_mnt() in *two* places.
>>>> The first of these is the call that creates the "hidden" mount ID that
>>>> becomes the parent of the root mount point. (I verified this by
>>>> instrumenting the kernel with a few printk() calls to display the
>>>> IDs.) The second place where copy_tree() calls clone_mnt() is in a
>>>> loop that replicates each of the mount points (including the root
>>>> mount point) in the source mount namespace.
>>>
>>> We used to report that mount, ones upon a time. Something has changed
>>> the behavior since then and its not reported any more, thus making it
>>> hidden.
>>
>> The hidden one is the initramfs, I believe. That's the root of the
>> mount namespace, and the when a namespace is cloned, the tree is
>> copied from the namespace root.
>>
>> It is "hidden" because no process has its root there. Note the
>> difference between namespace root and process root: the first is the
>> real root of the mount tree and is unchangeable, the second is
>> pointing to some place in a mount tree and can be changed (chroot).
>>
>> So there's nothing special in this rootfs, it is just hidden because
>> it's not the root of any task.
>>
>> The description of field (2) is correct, it just does not make it
>> clear what it means by "root".
>
> Sorry -- do you mean the old description is correct, or my new
> description (below)?
Well, both are correct, yours just describes the same thing at the
higher level. But I think rootfs is an implementation detail, so is
the fact that it gets a zero mount ID, so I think the original
description better captures the essence of the interface. Except it
needs to clarify what "top of the mount tree" means. It doesn't mean
current process's root, rather it means the root of the mount tree in
the current mount namespace.
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Improving documentation of parent-ID field in /proc/PID/mountinfo
2017-11-14 16:16 ` Miklos Szeredi
(?)
@ 2017-11-20 9:07 ` Michael Kerrisk (man-pages)
2017-11-20 9:22 ` Miklos Szeredi
2017-11-21 3:19 ` Ram Pai
-1 siblings, 2 replies; 12+ messages in thread
From: Michael Kerrisk (man-pages) @ 2017-11-20 9:07 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: Ram Pai, lkml, linux-man, Alexander Eder, linux-fsdevel
Hi Miklos,
Sorry for the slow follow-up.
On 14 November 2017 at 17:16, Miklos Szeredi <mszeredi@redhat.com> wrote:
> On Tue, Nov 14, 2017 at 8:08 AM, Michael Kerrisk (man-pages)
> <mtk.manpages@gmail.com> wrote:
>> Hi Miklos, Ram
>>
>> Thanks for your comments. A question below.
>>
>> On 13 November 2017 at 09:11, Miklos Szeredi <mszeredi@redhat.com> wrote:
>>> On Mon, Nov 13, 2017 at 8:55 AM, Ram Pai <linuxram@us.ibm.com> wrote:
>>>> On Mon, Nov 13, 2017 at 07:02:21AM +0100, Michael Kerrisk (man-pages) wrote:
>>>>> Hello Ram,
>>>>>
>>>>> Long ago (2.6.29) you added the /proc/PID/mountinfo file and
>>>>> associated documentation in Documentation/filesystems/proc.txt. Later,
>>>>> I pasted much of that documentation into the proc(5) manual page.
>>>>>
>>>>> That documentation says of the second field in the file:
>>>>>
>>>>> [[
>>>>> This file contains lines of the form:
>>>>>
>>>>> 36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue
>>>>> (1)(2)(3) (4) (5) (6) (7) (8) (9) (10) (11)
>>>>>
>>>>> (1) mount ID: unique identifier of the mount (may be reused after umount)
>>>>> (2) parent ID: ID of parent (or of self for the top of the mount tree)
>>>>> ...
>>>>> ]]
>>>>>
>>>>> The last piece of the description of field (2) doesn't seem to be
>>>>> correct, or is at least rather unclear. I take this to be saying that
>>>>> that for the root mount point, /, field (2) will have the same value
>>>>> as field (1). I never actually looked at this detail closely, but
>>>>> Alexander pointed out that this is obviously not so, as one can
>>>>> immediately verify:
>>>>>
>>>>> $ grep '/ / ' /proc/$$/mountinfo
>>>>> 65 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,seclabel,data=order
>>>>>
>>>>> I dug around in the kernel source for a bit. I do not have an exact
>>>>> handle on the details, but I can see roughly what is going on.
>>>>> Internally, there seems to be one ("hidden") mount ID reserved to each
>>>>> mount namespace, and that ID is the parent of the root mount point.
>>>>>
>>>>> Looking through the (4.14) kernel source, mount IDs are allocated by
>>>>> mnt_alloc_id() (in fs/namespace.c), which is in turn called by
>>>>> alloc_vfsmnt() which is in turn called by clone_mnt().
>>>>>
>>>>> A new mount namespace is created by the kernel function copy_mnt_ns()
>>>>> (in fs/namespace.c, called by create_new_namespaces() in
>>>>> kernel/nsproxy.c). The copy_mnt_ns() function calls copy_tree() (in
>>>>> fs/namespace.c), and copy_tree() calls clone_mnt() in *two* places.
>>>>> The first of these is the call that creates the "hidden" mount ID that
>>>>> becomes the parent of the root mount point. (I verified this by
>>>>> instrumenting the kernel with a few printk() calls to display the
>>>>> IDs.) The second place where copy_tree() calls clone_mnt() is in a
>>>>> loop that replicates each of the mount points (including the root
>>>>> mount point) in the source mount namespace.
>>>>
>>>> We used to report that mount, ones upon a time. Something has changed
>>>> the behavior since then and its not reported any more, thus making it
>>>> hidden.
>>>
>>> The hidden one is the initramfs, I believe. That's the root of the
>>> mount namespace, and the when a namespace is cloned, the tree is
>>> copied from the namespace root.
>>>
>>> It is "hidden" because no process has its root there. Note the
>>> difference between namespace root and process root: the first is the
>>> real root of the mount tree and is unchangeable, the second is
>>> pointing to some place in a mount tree and can be changed (chroot).
>>>
>>> So there's nothing special in this rootfs, it is just hidden because
>>> it's not the root of any task.
>>>
>>> The description of field (2) is correct, it just does not make it
>>> clear what it means by "root".
>>
>> Sorry -- do you mean the old description is correct, or my new
>> description (below)?
>
> Well, both are correct, yours just describes the same thing at the
> higher level. But I think rootfs is an implementation detail, so is
> the fact that it gets a zero mount ID, so I think the original
> description better captures the essence of the interface. Except it
> needs to clarify what "top of the mount tree" means. It doesn't mean
> current process's root, rather it means the root of the mount tree in
> the current mount namespace.
Thanks for the further info.
But, the problem is that the existing description is at best misleading:
(2) parent ID: the ID of the parent mount (or of self for
the top of the mount tree).
That implies that we'll find one line in the list where field 1 and
field 2 are the same. But we don't, because the mountns rootfs entry
is not shown in mountinfo. On top of that, the reader is left
confused, because when they look at mountinfo, they see one entry
where the parent-ID doesn't exist in the list. So, something more than
the current text is required. After digging around in the kernel
source and noticing that chroot() will also cause this scenario, and
taking into account your comments, I revised the text to:
(2) parent ID: the ID of the parent mount (or of self for
the root of this mount namespace's mount tree).
If the parent mount point lies outside the process's
root directory (see chroot(2)), the ID shown here
won't have a corresponding record in mountinfo whose
mount ID (field 1) matches this parent mount ID
(because mount points that lie outside the process's
root directory are not shown in mountinfo). As a spe‐
cial case of this point, the process's root mount
point may have a parent mount (for the initramfs
filesystem) that lies outside the process's root
directory, and an entry for that mount point will not
appear in mountinfo.
How does that seem?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Improving documentation of parent-ID field in /proc/PID/mountinfo
2017-11-20 9:07 ` Michael Kerrisk (man-pages)
@ 2017-11-20 9:22 ` Miklos Szeredi
2017-11-20 9:37 ` Michael Kerrisk (man-pages)
2017-11-21 3:19 ` Ram Pai
1 sibling, 1 reply; 12+ messages in thread
From: Miklos Szeredi @ 2017-11-20 9:22 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: Ram Pai, lkml, linux-man, Alexander Eder, linux-fsdevel
On Mon, Nov 20, 2017 at 10:07 AM, Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
> But, the problem is that the existing description is at best misleading:
>
> (2) parent ID: the ID of the parent mount (or of self for
> the top of the mount tree).
>
> That implies that we'll find one line in the list where field 1 and
> field 2 are the same. But we don't, because the mountns rootfs entry
> is not shown in mountinfo. On top of that, the reader is left
> confused, because when they look at mountinfo, they see one entry
> where the parent-ID doesn't exist in the list. So, something more than
> the current text is required. After digging around in the kernel
> source and noticing that chroot() will also cause this scenario, and
> taking into account your comments, I revised the text to:
>
> (2) parent ID: the ID of the parent mount (or of self for
> the root of this mount namespace's mount tree).
>
> If the parent mount point lies outside the process's
> root directory (see chroot(2)), the ID shown here
> won't have a corresponding record in mountinfo whose
> mount ID (field 1) matches this parent mount ID
> (because mount points that lie outside the process's
> root directory are not shown in mountinfo). As a spe‐
> cial case of this point, the process's root mount
> point may have a parent mount (for the initramfs
> filesystem) that lies outside the process's root
> directory, and an entry for that mount point will not
> appear in mountinfo.
>
> How does that seem?
Perfect.
Thanks,
Miklos
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Improving documentation of parent-ID field in /proc/PID/mountinfo
2017-11-20 9:22 ` Miklos Szeredi
@ 2017-11-20 9:37 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 12+ messages in thread
From: Michael Kerrisk (man-pages) @ 2017-11-20 9:37 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: Ram Pai, lkml, linux-man, Alexander Eder, linux-fsdevel
Hello Miklos,
On 20 November 2017 at 10:22, Miklos Szeredi <mszeredi@redhat.com> wrote:
> On Mon, Nov 20, 2017 at 10:07 AM, Michael Kerrisk (man-pages)
> <mtk.manpages@gmail.com> wrote:
>
>> But, the problem is that the existing description is at best misleading:
>>
>> (2) parent ID: the ID of the parent mount (or of self for
>> the top of the mount tree).
>>
>> That implies that we'll find one line in the list where field 1 and
>> field 2 are the same. But we don't, because the mountns rootfs entry
>> is not shown in mountinfo. On top of that, the reader is left
>> confused, because when they look at mountinfo, they see one entry
>> where the parent-ID doesn't exist in the list. So, something more than
>> the current text is required. After digging around in the kernel
>> source and noticing that chroot() will also cause this scenario, and
>> taking into account your comments, I revised the text to:
>>
>> (2) parent ID: the ID of the parent mount (or of self for
>> the root of this mount namespace's mount tree).
>>
>> If the parent mount point lies outside the process's
>> root directory (see chroot(2)), the ID shown here
>> won't have a corresponding record in mountinfo whose
>> mount ID (field 1) matches this parent mount ID
>> (because mount points that lie outside the process's
>> root directory are not shown in mountinfo). As a spe‐
>> cial case of this point, the process's root mount
>> point may have a parent mount (for the initramfs
>> filesystem) that lies outside the process's root
>> directory, and an entry for that mount point will not
>> appear in mountinfo.
>>
>> How does that seem?
>
> Perfect.
Thanks! And thanks for the fast review and response.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Improving documentation of parent-ID field in /proc/PID/mountinfo
2017-11-20 9:07 ` Michael Kerrisk (man-pages)
2017-11-20 9:22 ` Miklos Szeredi
@ 2017-11-21 3:19 ` Ram Pai
1 sibling, 0 replies; 12+ messages in thread
From: Ram Pai @ 2017-11-21 3:19 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: Miklos Szeredi, lkml, linux-man, Alexander Eder, linux-fsdevel
On Mon, Nov 20, 2017 at 10:07:29AM +0100, Michael Kerrisk (man-pages) wrote:
> Hi Miklos,
>
> Sorry for the slow follow-up.
>
> On 14 November 2017 at 17:16, Miklos Szeredi <mszeredi@redhat.com> wrote:
> > On Tue, Nov 14, 2017 at 8:08 AM, Michael Kerrisk (man-pages)
> > <mtk.manpages@gmail.com> wrote:
> >> Hi Miklos, Ram
> >>
> >> Thanks for your comments. A question below.
> >>
> >> On 13 November 2017 at 09:11, Miklos Szeredi <mszeredi@redhat.com> wrote:
> >>> On Mon, Nov 13, 2017 at 8:55 AM, Ram Pai <linuxram@us.ibm.com> wrote:
> >>>> On Mon, Nov 13, 2017 at 07:02:21AM +0100, Michael Kerrisk (man-pages) wrote:
> >>>>> Hello Ram,
> >>>>>
> >>>>> Long ago (2.6.29) you added the /proc/PID/mountinfo file and
> >>>>> associated documentation in Documentation/filesystems/proc.txt. Later,
> >>>>> I pasted much of that documentation into the proc(5) manual page.
> >>>>>
> >>>>> That documentation says of the second field in the file:
> >>>>>
> >>>>> [[
> >>>>> This file contains lines of the form:
> >>>>>
> >>>>> 36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue
> >>>>> (1)(2)(3) (4) (5) (6) (7) (8) (9) (10) (11)
> >>>>>
> >>>>> (1) mount ID: unique identifier of the mount (may be reused after umount)
> >>>>> (2) parent ID: ID of parent (or of self for the top of the mount tree)
> >>>>> ...
> >>>>> ]]
> >>>>>
> >>>>> The last piece of the description of field (2) doesn't seem to be
> >>>>> correct, or is at least rather unclear. I take this to be saying that
> >>>>> that for the root mount point, /, field (2) will have the same value
> >>>>> as field (1). I never actually looked at this detail closely, but
> >>>>> Alexander pointed out that this is obviously not so, as one can
> >>>>> immediately verify:
> >>>>>
> >>>>> $ grep '/ / ' /proc/$$/mountinfo
> >>>>> 65 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,seclabel,data=order
> >>>>>
> >>>>> I dug around in the kernel source for a bit. I do not have an exact
> >>>>> handle on the details, but I can see roughly what is going on.
> >>>>> Internally, there seems to be one ("hidden") mount ID reserved to each
> >>>>> mount namespace, and that ID is the parent of the root mount point.
> >>>>>
> >>>>> Looking through the (4.14) kernel source, mount IDs are allocated by
> >>>>> mnt_alloc_id() (in fs/namespace.c), which is in turn called by
> >>>>> alloc_vfsmnt() which is in turn called by clone_mnt().
> >>>>>
> >>>>> A new mount namespace is created by the kernel function copy_mnt_ns()
> >>>>> (in fs/namespace.c, called by create_new_namespaces() in
> >>>>> kernel/nsproxy.c). The copy_mnt_ns() function calls copy_tree() (in
> >>>>> fs/namespace.c), and copy_tree() calls clone_mnt() in *two* places.
> >>>>> The first of these is the call that creates the "hidden" mount ID that
> >>>>> becomes the parent of the root mount point. (I verified this by
> >>>>> instrumenting the kernel with a few printk() calls to display the
> >>>>> IDs.) The second place where copy_tree() calls clone_mnt() is in a
> >>>>> loop that replicates each of the mount points (including the root
> >>>>> mount point) in the source mount namespace.
> >>>>
> >>>> We used to report that mount, ones upon a time. Something has changed
> >>>> the behavior since then and its not reported any more, thus making it
> >>>> hidden.
> >>>
> >>> The hidden one is the initramfs, I believe. That's the root of the
> >>> mount namespace, and the when a namespace is cloned, the tree is
> >>> copied from the namespace root.
> >>>
> >>> It is "hidden" because no process has its root there. Note the
> >>> difference between namespace root and process root: the first is the
> >>> real root of the mount tree and is unchangeable, the second is
> >>> pointing to some place in a mount tree and can be changed (chroot).
> >>>
> >>> So there's nothing special in this rootfs, it is just hidden because
> >>> it's not the root of any task.
> >>>
> >>> The description of field (2) is correct, it just does not make it
> >>> clear what it means by "root".
> >>
> >> Sorry -- do you mean the old description is correct, or my new
> >> description (below)?
> >
> > Well, both are correct, yours just describes the same thing at the
> > higher level. But I think rootfs is an implementation detail, so is
> > the fact that it gets a zero mount ID, so I think the original
> > description better captures the essence of the interface. Except it
> > needs to clarify what "top of the mount tree" means. It doesn't mean
> > current process's root, rather it means the root of the mount tree in
> > the current mount namespace.
>
> Thanks for the further info.
>
> But, the problem is that the existing description is at best misleading:
>
> (2) parent ID: the ID of the parent mount (or of self for
> the top of the mount tree).
>
> That implies that we'll find one line in the list where field 1 and
> field 2 are the same. But we don't, because the mountns rootfs entry
> is not shown in mountinfo. On top of that, the reader is left
> confused, because when they look at mountinfo, they see one entry
> where the parent-ID doesn't exist in the list. So, something more than
> the current text is required. After digging around in the kernel
> source and noticing that chroot() will also cause this scenario, and
> taking into account your comments, I revised the text to:
>
> (2) parent ID: the ID of the parent mount (or of self for
> the root of this mount namespace's mount tree).
>
> If the parent mount point lies outside the process's
> root directory (see chroot(2)), the ID shown here
> won't have a corresponding record in mountinfo whose
> mount ID (field 1) matches this parent mount ID
> (because mount points that lie outside the process's
> root directory are not shown in mountinfo). As a spe‐
> cial case of this point, the process's root mount
> point may have a parent mount (for the initramfs
> filesystem) that lies outside the process's root
> directory, and an entry for that mount point will not
> appear in mountinfo.
>
> How does that seem?
yes. captures it well.
RP
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-11-21 3:19 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-13 6:02 Improving documentation of parent-ID field in /proc/PID/mountinfo Michael Kerrisk (man-pages)
2017-11-13 6:02 ` Michael Kerrisk (man-pages)
2017-11-13 7:55 ` Ram Pai
2017-11-13 8:11 ` Miklos Szeredi
2017-11-14 7:08 ` Michael Kerrisk (man-pages)
2017-11-14 7:08 ` Michael Kerrisk (man-pages)
2017-11-14 16:16 ` Miklos Szeredi
2017-11-14 16:16 ` Miklos Szeredi
2017-11-20 9:07 ` Michael Kerrisk (man-pages)
2017-11-20 9:22 ` Miklos Szeredi
2017-11-20 9:37 ` Michael Kerrisk (man-pages)
2017-11-21 3:19 ` Ram Pai
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.