* Mount namespace "dominant peer group"?
@ 2016-05-20 21:24 Michael Kerrisk (man-pages)
2016-05-20 23:15 ` Ram Pai
0 siblings, 1 reply; 5+ messages in thread
From: Michael Kerrisk (man-pages) @ 2016-05-20 21:24 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: mtk.manpages, lkml, Serge E. Hallyn, Al Viro, Ram Pai
Hello Miklos,
I'm working on some better documentation of mount namespaces,
and there's a detail that puzzles me, and I hope you might be
able to help, since you added the detail...
In Documentation/filesystems/proc.txt there is this text in the
description of /proc/PID/mountinfo:
[[
Parsers should ignore all unrecognised optional fields. Currently the
possible optional fields are:
shared:X mount is shared in peer group X
master:X mount is slave to peer group X
propagate_from:X mount is slave and receives propagation from peer group X (*)
unbindable mount is unbindable
(*) X is the closest dominant peer group under the process's root. If
X is the immediate master of the mount, or if there's no dominant peer
group under the same root, then only the "master:X" field is present
and not the "propagate_from:X" field.
]]
What is a dominant peer group, as distinct from the immediate master?
I can see in fs/proc_namespaces.c that there is this distinction made:
[[
/* Tagged fields ("foo:X" or "bar") */
if (IS_MNT_SHARED(r))
seq_printf(m, " shared:%i", r->mnt_group_id);
if (IS_MNT_SLAVE(r)) {
int master = r->mnt_master->mnt_group_id;
int dom = get_dominating_id(r, &p->root);
seq_printf(m, " master:%i", master);
if (dom && dom != master)
seq_printf(m, " propagate_from:%i", dom);
}
]]
But I can't relate that to some user-space semantics. I suppose another
way of asking my question is: how could I create a slave that is
propagating from a peer group other than it's immediate master?
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] 5+ messages in thread* Re: Mount namespace "dominant peer group"? 2016-05-20 21:24 Mount namespace "dominant peer group"? Michael Kerrisk (man-pages) @ 2016-05-20 23:15 ` Ram Pai 2016-05-21 12:49 ` Michael Kerrisk (man-pages) 0 siblings, 1 reply; 5+ messages in thread From: Ram Pai @ 2016-05-20 23:15 UTC (permalink / raw) To: Michael Kerrisk (man-pages) Cc: Miklos Szeredi, lkml, Serge E. Hallyn, Al Viro On Fri, May 20, 2016 at 04:24:18PM -0500, Michael Kerrisk (man-pages) wrote: > Hello Miklos, > > I'm working on some better documentation of mount namespaces, > and there's a detail that puzzles me, and I hope you might be > able to help, since you added the detail... > > In Documentation/filesystems/proc.txt there is this text in the > description of /proc/PID/mountinfo: > > [[ > Parsers should ignore all unrecognised optional fields. Currently the > possible optional fields are: > > shared:X mount is shared in peer group X > master:X mount is slave to peer group X > propagate_from:X mount is slave and receives propagation from peer group X (*) > unbindable mount is unbindable > > (*) X is the closest dominant peer group under the process's root. If > X is the immediate master of the mount, or if there's no dominant peer > group under the same root, then only the "master:X" field is present > and not the "propagate_from:X" field. > ]] > > What is a dominant peer group, as distinct from the immediate master? > > I can see in fs/proc_namespaces.c that there is this distinction made: > > [[ > /* Tagged fields ("foo:X" or "bar") */ > if (IS_MNT_SHARED(r)) > seq_printf(m, " shared:%i", r->mnt_group_id); > if (IS_MNT_SLAVE(r)) { > int master = r->mnt_master->mnt_group_id; > int dom = get_dominating_id(r, &p->root); > seq_printf(m, " master:%i", master); > if (dom && dom != master) > seq_printf(m, " propagate_from:%i", dom); > } > ]] > > But I can't relate that to some user-space semantics. I suppose another > way of asking my question is: how could I create a slave that is > propagating from a peer group other than it's immediate master? It can happen if you have unmounted or privatised all your master mounts from the peer group. Eg: mount /dev/xyz /1 #creates a new mount mount --make-private /1 #just make sure that it does not receive or send and propogation mount --make-shared /1 #now make it shared. mount --bind /1 /2 #create a peer /1 and /2 are peers create a new fs-namespace. this new fs-namespace which will have /1' and /2'. /1 /2 /1' /2' are now all part of the same peergroup. mount --make-slave /2 # this will make /2 a slave of the peer group that contains /1 /1' and /2' umount /1 # we now have /2 which receives propagation from a peer group which does not have a representative in its fs-namespace. RP > > Cheers, > > Michael > > -- > Michael Kerrisk > Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ > Linux/UNIX System Programming Training: http://man7.org/training/ -- Ram Pai ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Mount namespace "dominant peer group"? 2016-05-20 23:15 ` Ram Pai @ 2016-05-21 12:49 ` Michael Kerrisk (man-pages) 2016-05-23 7:55 ` Miklos Szeredi 0 siblings, 1 reply; 5+ messages in thread From: Michael Kerrisk (man-pages) @ 2016-05-21 12:49 UTC (permalink / raw) To: Ram Pai; +Cc: mtk.manpages, Miklos Szeredi, lkml, Serge E. Hallyn, Al Viro Hello Ram, On 05/20/2016 06:15 PM, Ram Pai wrote: > On Fri, May 20, 2016 at 04:24:18PM -0500, Michael Kerrisk (man-pages) wrote: >> Hello Miklos, >> >> I'm working on some better documentation of mount namespaces, >> and there's a detail that puzzles me, and I hope you might be >> able to help, since you added the detail... >> >> In Documentation/filesystems/proc.txt there is this text in the >> description of /proc/PID/mountinfo: >> >> [[ >> Parsers should ignore all unrecognised optional fields. Currently the >> possible optional fields are: >> >> shared:X mount is shared in peer group X >> master:X mount is slave to peer group X >> propagate_from:X mount is slave and receives propagation from peer group X (*) >> unbindable mount is unbindable >> >> (*) X is the closest dominant peer group under the process's root. If >> X is the immediate master of the mount, or if there's no dominant peer >> group under the same root, then only the "master:X" field is present >> and not the "propagate_from:X" field. >> ]] >> >> What is a dominant peer group, as distinct from the immediate master? >> >> I can see in fs/proc_namespaces.c that there is this distinction made: >> >> [[ >> /* Tagged fields ("foo:X" or "bar") */ >> if (IS_MNT_SHARED(r)) >> seq_printf(m, " shared:%i", r->mnt_group_id); >> if (IS_MNT_SLAVE(r)) { >> int master = r->mnt_master->mnt_group_id; >> int dom = get_dominating_id(r, &p->root); >> seq_printf(m, " master:%i", master); >> if (dom && dom != master) >> seq_printf(m, " propagate_from:%i", dom); >> } >> ]] >> >> But I can't relate that to some user-space semantics. I suppose another >> way of asking my question is: how could I create a slave that is >> propagating from a peer group other than it's immediate master? > > It can happen if you have unmounted or privatised all your master mounts from the peer group. > > Eg: > > mount /dev/xyz /1 #creates a new mount > mount --make-private /1 #just make sure that it does not receive or send and propogation > mount --make-shared /1 #now make it shared. > mount --bind /1 /2 #create a peer /1 and /2 are peers > create a new fs-namespace. this new fs-namespace which will have /1' and /2'. /1 /2 /1' /2' are now all part of the same peergroup. > mount --make-slave /2 # this will make /2 a slave of the peer group that contains /1 /1' and /2' > umount /1 # we now have /2 which receives propagation from a peer group which does not have a representative in its fs-namespace. Thanks for the note. However, doing the above, I still do not see any mount being marked with 'propagate_from'. Perhaps I misunderstood your instructions above. Here's what I did: sh1# mount --make-private / # Make share everything is private... sh1# mount /dev/sdb6 /1 sh1# mount --make-private /1 sh1# mount --make-shared /1 sh1# mount --bind /1 /2 sh1# cat /proc/self/mountinfo | grep '/[12] ' | sed 's/ - .*//' 81 61 8:22 / /1 rw,relatime shared:1 82 61 8:22 / /2 rw,relatime shared:1 Then, at a second terminal, create a new mount NS: sh2# unshare -m --propagation unchanged sh sh2# cat /proc/self/mountinfo | grep '/[12] ' | sed 's/ - .*//' 169 132 8:22 / /1 rw,relatime shared:1 170 132 8:22 / /2 rw,relatime shared:1 Returning to the first terminal: sh1# mount --make-slave /2 sh1# umount /1 sh1# cat /proc/self/mountinfo | grep '/[12] ' | sed 's/ - .*//' 82 61 8:22 / /2 rw,relatime master:1 That is, we see /2 in the initial mount namespace is a slave but there is no 'propagate_from' tag. Did I miss something? 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] 5+ messages in thread
* Re: Mount namespace "dominant peer group"? 2016-05-21 12:49 ` Michael Kerrisk (man-pages) @ 2016-05-23 7:55 ` Miklos Szeredi 2016-05-24 22:57 ` Michael Kerrisk (man-pages) 0 siblings, 1 reply; 5+ messages in thread From: Miklos Szeredi @ 2016-05-23 7:55 UTC (permalink / raw) To: Michael Kerrisk (man-pages); +Cc: Ram Pai, lkml, Serge E. Hallyn, Al Viro C is slave of B is slave of A. If a process can see (i.e. has under its root) A and C but not B then for C it will show master:B,propagate_from:A. This piece of information is shown because it can't see the immediate master (B) and so cannot determine the chain of propagation between the mounts it can see. Concrete example: # mount --bind / /mnt # mount --bind /proc /mnt/proc # mount --make-private /mnt # mount --make-shared /mnt # mkdir /tmp/etc # mount --bind /mnt/etc /tmp/etc # mount --make-slave /tmp/etc # mount --make-shared /tmp/etc # mount --bind /tmp/etc /mnt/tmp/etc # mount --make-slave /mnt/tmp/etc # cat /proc/self/mountinfo | grep /tmp/etc 164 40 253:1 /etc /tmp/etc rw,relatime shared:100 master:97 - ... # chroot /mnt # cat /proc/self/mountinfo 129 62 253:1 / / rw,relatime shared:97 - ... 168 129 253:1 /etc /tmp/etc rw,relatime master:100 propagate_from:97 - ... Thanks, Miklos ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Mount namespace "dominant peer group"? 2016-05-23 7:55 ` Miklos Szeredi @ 2016-05-24 22:57 ` Michael Kerrisk (man-pages) 0 siblings, 0 replies; 5+ messages in thread From: Michael Kerrisk (man-pages) @ 2016-05-24 22:57 UTC (permalink / raw) To: Miklos Szeredi; +Cc: mtk.manpages, Ram Pai, lkml, Serge E. Hallyn, Al Viro On 05/23/2016 02:55 AM, Miklos Szeredi wrote: > C is slave of B is slave of A. If a process can see (i.e. has under > its root) A and C but not B then for C it will show > master:B,propagate_from:A. This piece of information is shown because > it can't see the immediate master (B) and so cannot determine the > chain of propagation between the mounts it can see. Thanks, Miklos! > Concrete example: Yep, that does it. Thanks for the walk through! One piece missing below though, in case anyone else tries to walk through. > # mount --bind / /mnt > # mount --bind /proc /mnt/proc > # mount --make-private /mnt > # mount --make-shared /mnt > # mkdir /tmp/etc > # mount --bind /mnt/etc /tmp/etc > # mount --make-slave /tmp/etc > # mount --make-shared /tmp/etc # mkdir /mnt/tmp/etc > # mount --bind /tmp/etc /mnt/tmp/etc > # mount --make-slave /mnt/tmp/etc > # cat /proc/self/mountinfo | grep /tmp/etc > 164 40 253:1 /etc /tmp/etc rw,relatime shared:100 master:97 - ... > # chroot /mnt > # cat /proc/self/mountinfo > 129 62 253:1 / / rw,relatime shared:97 - ... > 168 129 253:1 /etc /tmp/etc rw,relatime master:100 propagate_from:97 - ... 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] 5+ messages in thread
end of thread, other threads:[~2016-05-24 22:58 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-05-20 21:24 Mount namespace "dominant peer group"? Michael Kerrisk (man-pages) 2016-05-20 23:15 ` Ram Pai 2016-05-21 12:49 ` Michael Kerrisk (man-pages) 2016-05-23 7:55 ` Miklos Szeredi 2016-05-24 22:57 ` Michael Kerrisk (man-pages)
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
Powered by JetHome