Re: UML mount failure with Linux 6.11

[Johannes Berg <johannes@sipsolutions.net>]

Hi,

> > 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.

I'm not sure using the old mount API would work because the kernel
converted internally to the new one now. Anyway it'd still be a kernel
regression if we have to fix it in userspace, no? :)

> > 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)

So I guess that means for paths without comma (almost certainly the
overwhelming majority) we could somehow work around it in the kernel.
Hongbo, what do you think?

> > 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)

I think it's a matter of not regressing for users, if they just update
the kernel and have old or existing mount tools. And I'm not convinced
using the old API will actually fix the issue, I think maybe the kernel
itself would break that too by parsing it now for the new API?

> 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.

Right, but we already have that - you can specify hostfs="quoted path"
when everything is new and it'll work just fine?

Question is more around the regression, to me.

johannes