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@xxxxxxxxxx>
http://karelzak.blogspot.com
