UML mount failure with Linux 6.11

[Karel Zak]

On Wed, Nov 27, 2024 at 02:15:54PM GMT, Johannes Berg wrote:
> Let me try to unify the threads, and perhaps further my understanding -
> you seem to already have much more of that than me :)
> 
> > > > But this is still a regression, so we need to figure out what to do
> > > > short term?
> > > > 
> > > So for short term, even long term, can we consider handling the hostfs
> > > situation specially within libmount?
> > 
> > Yes (see reply to Johannes ).
> 
> I'd argue though that this doesn't count as fixing the regression, since
> the kernel was fine before the changes there (even before porting hostfs
> to the new API) with _any_ version of userspace. Except perhaps for when
> there's a comma in the path, which I suppose would've broken one way or
> the other by mount(8) moving to the new API?

Another option is to hardcode a libmount exception that, for hostfs,
the default behavior should be to use the classic mount(2) syscall if
the hostfs= option is not present.
    
 -t hostfs -o /home/hostfs,dir          --> mount(8)
 -t hostfs -o hostfs="/home/hostfs,dir" --> new API

(Alternatively, use the old mount(8) for hostfs regardless of the
options chosen.)

> Assuming no commas, would mount(8) today send the path as the key to a
> flag option? 

 Yes, (I have no hostfs here, so example with ext4):

 # strace -e fsconfig mount -t ext4 -o /home/hostfs none /mnt/test

 fsconfig(3, FSCONFIG_SET_STRING, "source", "none", 0) = 0
 fsconfig(3, FSCONFIG_SET_FLAG, "/home/hostfs", NULL, 0) = -1 EINVAL (Invalid argument)

> We could perhaps find a way to handle that in the kernel,
> and then just do the longer-term plan of moving users to hostfs="..."
> (by documentation/warning) in the future?

The question is whether investing time in using the path-as-key
approach makes sense. Perhaps it would be better to stick with the old
mount(2) and focus on developing a new API that does not have any
legacy issues. Users who choose to use the hostfs= option and the new
kernel will be able to utilize the new API.

    Karel

-- 
 Karel Zak  <kzak at redhat.com>
 http://karelzak.blogspot.com