[systemd-devel] [PATCH] path_is_mount_point: handle false positive on some fs

Lennart Poettering lennart at poettering.net
Tue Mar 10 08:53:38 PDT 2015

On Mon, 09.03.15 11:27, Didier Roche (didrocks at ubuntu.com) wrote:

> However, some file systems (seems overlayfs at least) would report a
> major(st_dev) as 0 on directories and not on files. The current
> path_is_mount_point() fallback logic would thus reports that every files is
> a mount point. The enclosed patch introduces a second fallback to read
> /proc/mounts, and ensures there is no shadowing by later mounting of parent
> directories. This slower path is only used when the 2 first methods failed
> to determine with assurance if the path is a mount point or not.

Humppf, I am not convinced this is really a good idea.

I mean, we use name_to_handle_at() precisely for the reason that we
don't want to parse /proc/self/mountinfo, since that is really
cumbersome if you want to do it properly, given that mounts can
obstruct other mounts and symlink/realpath complexity and stuff.

Note that the st_dev thing is the traditional way to detect whether
one crosses a file system boundary. It's used for this by tools like
cp, find, .... We slightly enhance this by using name_to_handle_at(),
so that we can also detect bind mounts from file systems onto
themselves. Now, if overlayfs breaks the same file system logic of all
other tools, I am not convinced that systemd should not be broken by
it too.. It sounds surprising that we should work around this in
systemd, but not in all other tools. 

Or to turn this around: instead of patching systemd the better idea
would probably be to teach overlayfs name_to_handle_at() support, so
that there's a way to detect the mount id from such a file system in a
safe way.

Hmm, where precisely did you run into problems with this?


Lennart Poettering, Red Hat

More information about the systemd-devel mailing list