On Fri, Jun 06, 2025 at 06:45:02PM +0100, Al Viro wrote:
> On Fri, Jun 06, 2025 at 09:58:26AM +0200, Christian Brauner wrote:
>
> > Fwiw, check_mnt() is a useless name for this function that's been
> > bothering me forever.
>
> Point, but let's keep the renaming (s/check_mnt/our_mount/, for
> example) separate.
Modified and force-pushed.
It does pass xfstests without regressions. kselftests... AFAICS,
no regressions either, but the damn thing is a mess. Example:
# # set_layers_via_fds.c:711:set_layers_via_detached_mount_fds:Expected layers_found[i] (0) == true (1)
# # set_layers_via_fds.c:39:set_layers_via_detached_mount_fds:Expected rmdir("/set_layers_via_fds") (-1) == 0 (0)
# # set_layers_via_detached_mount_fds: Test terminated by assertion
# # FAIL set_layers_via_fds.set_layers_via_detached_mount_fds
Not a regression, AFAICT; the underlying problem is that mount options
are shown incorrectly in the tested case. Still present after overlayfs
merge. mount does succeed, but... in options we see this:
rw,relatime,lowerdir+=/,lowerdir+=/,lowerdir+=/,lowerdir+=/,datadir+=/,datadir+=/,datadir+=/,upperdir=/upper,workdir=/work,redirect_dir=on,uuid=on,metacopy=on
And it's a perfectly expected result - you are giving fsconfig(2) empty
path on a detached tree, created with OPEN_TREE_CLONE. I.e. it *is*
an empty path in the mount tree the sucker's in. What could d_path()
produce other than "/"?
Note, BTW that it really does create set_layers_via_fds in root (WTF?) and
running that sucker again yields a predictable fun result - mkdir() failing
with EEXIST...
IMO that kind of stuff should be dealt with by creating a temporary directory
somewhere in /tmp, mounting tmpfs on it, then doing all creations, etc.
inside that. Then umount -l /tmp/<whatever>; rmdir /tmp/<whatever> will
clean the things up.
