Re: UML mount failure with Linux 6.11

[Johannes Berg <johannes@sipsolutions.net>]

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?

I'd kind of prefer we fixed the immediate regression, at least without
the comma, in the kernel. But I guess you can do whatever you can get
away with ;-) And it's already broken for two kernel releases now ...
but I guess those haven't percolated through the ecosystem *that* much.

[from the other email]
> I can add a temporary workaround to libmount for hostfs, which will
> automatically add the hostfs= key for unnamed paths. This will allow
> you to receive the expected fsconfig() data from userspace.

so I'm not sure this makes too much sense - kernel upgrade broke it, I
guess kernel upgrade should try to fix it?

Assuming no commas, would mount(8) today send the path as the key to a
flag option? 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?


> > Such as treat the whole option as one
> > key(also may be with comma, even with equal)
> 
> There could be userspace specific options, VFS flags, etc.
> 
>   -o /home/hostfs,ro,noexec
> 
> Is it one path or path and two options?

Yeah but there _aren't_ in hostfs, right now. So without the mount API
we'd not even be asking that question since the parsing was in the fs
and hostfs would just never have done it, I guess?

> We can automatically add a key (e.g. hostfs=) and use FSCONFIG_SET_FLAG.
> The goal should be to get the path as a value, because key is limited to
> 256 bytes.

Right, we can do that going forward, but it doesn't really address the
regression?

johannes