Karel Zak <kzak@xxxxxxxxxx> writes: > On Thu, May 30, 2024 at 08:00:34PM +0200, Linus Heckemann wrote: >> Previously, the X-mount.subdir option would fail (mount exited with >> code 0, but the target was not mounted) when a helper was used. > > Do you have any examples that can easily reproduce it? I encountered this issue with bcachefs (create /foo in the root of a bcachefs filesystem and then attempt to mount that same filesystem with X-mount.subdir=foo) but the problem should be the same with any other filesystem that uses a mount helper. truncate -s 1G test.img mkfs.bcachefs test.img mount -o loop,X-mount.mkdir test.img /tmp/mnt mkdir /tmp/mnt/foo umount /tmp/mnt mount -o loop,X-mount.subdir=foo test.img /tmp/mnt Without my patch, this exits with status code 0 but does not result in /tmp/mnt being mounted at all. >> In addition to fixing X-mount.subdir, this allows dropping the >> fallback behaviour previously implemented specifically by the >> set_vfsflags and set_propagation hooks. >> >> I realise this patch is not acceptable as is, since I just exported >> the previously private open_mount_tree symbol from hook_mount.c > > Perhaps it is unnecessary to only keep the API file descriptors in > hook_mount.c. It is a generic feature and we may see more use > cases where it would make sense to use it in other places. > > I can imagine having the file descriptors in the libmnt_context > structure and initializing them through functions in context.c (which > would involve renaming open_mount_tree() to something more > appropriate). It could potentially be a public library function so > that libmount applications can also utilize it. > > I will think about it :-) Thanks! That sounds like it would make sense, though I'd expect (naively -- I'm not super familiar with the overall code) it's generally not desirable to use that function as opposed to using the mount fd from the context once it's become available through the mount step? I don't see a particularly strong case for using that and not open_tree directly.
