[PATCH] fs: store MS_BIND as MNT_BIND and show it in mountinfo

Seth Forshee seth.forshee at canonical.com
Thu Feb 2 15:45:39 UTC 2017


On Thu, Feb 02, 2017 at 02:21:04PM +0100, Zygmunt Krynicki wrote:
> This patch adds a new MNT_ flag that is set for bind mounts (it mirrors
> MS_BIND) and surfaces it via mountinfo. This allows for easier
> identification of mount entries that are bind mounted from somewhere
> else.
> 
> Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki at canonical.com>

This is a change in userspace ABI, so this is not something that we're
likely to take into Ubuntu without being sure that it will also be
accepted upstream.

However my expectation is that this patch would meet resistance or be
rejected outright upstream (explanation follows). Can you explain why
you need this?

Fundamentally "bind" refers to the mount operation and not to some
property of the mount itself. Once you've performed a bind mount the new
mount is more or less equivalent to the original - they have a peer
relationship and not a parent/child sort of relationship. The kernel
knows about the relationships between mounts, but whether or not one is
the original and the other was created via a bind mount operation is
irrelevant.

The relationship between two mounts can be seen from userspace using
/proc/<pid>/mountinfo. For example:

# mount -o loop fs.img a
# mount --bind a b
# mount --bind a/foo c
# cat /proc/self/mountinfo
...
158 26 7:0 / /home/ubuntu/bind-test/a rw,relatime shared:135 - ext4 /dev/loop0 rw,data=ordered
162 26 7:0 / /home/ubuntu/bind-test/b rw,relatime shared:135 - ext4 /dev/loop0 rw,data=ordered
166 26 7:0 /foo /home/ubuntu/bind-test/c rw,relatime shared:135 - ext4 /dev/loop0 rw,data=ordered

The "shared:135" indicates that these mounts are all part of the same
peer group (i.e. peer group 135). The mounts at .../a and .../b are
completely equivalent to the kernel.

It does show you that the mount at .../c is a little different.  The 4th
column indicates that the it mounts only a subtree of the filesystem. In
all other ways it is equivalent to the other two mounts.

Seth




More information about the kernel-team mailing list