Re: [PATCH 1/2] mount: fix detached mount regression

[Al Viro <viro@zeniv.linux.org.uk>]

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.