Mount namespace "dominant peer group"?

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

Signature · 3 lines

Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Quoted 39 lines · Michael Kerrisk (man-pages)

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);
        }

Quoted 5 lines

]]

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.

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 - ...