UML mount failure with Linux 6.11

[Karel Zak]

On Thu, Nov 21, 2024 at 09:53:06PM GMT, Hongbo Li wrote:
> > > The options has been always parsed by mount(8) and it's very fragile
> > > to assume that kernel get as in the original order (etc.).
> > > 
> > > For decades, commas have been supported in mount options. For example,
> > > SeLinux uses them frequently in context settings. All you need to do
> > > is use quotes, but be careful because the shell will strip them off.
> > > Therefore, double quoting is required.
> > > 
> > 
> > Thanks for your reply!
> > 
> > If I'm not mistaken, we should add double quoting explicitly if we need
> > commas in mount options. However, it seems different for hostfs. For
> > example, with hostfs, if we use "mount -t hostfs none -o
> > /home/hostfs,dir /mnt" in the older interface, which can successfully
> > mount the host directory `/home/hostfs,dir`, then we should use "mount
> > -t hostfs none -o '"/home/hostfs,dir"' /mnt" in the new interface. If
> > that is the case, we should change the mount command which is hardcoded
> > in the original project.
> Sorry for the disturbance. So am I right?

The old interface (mount(2)) sends all options together as one string.
This means that if mount(8)/libmount does not modify the string in an
unwanted way, then you are safe.

The new interface uses one fsconfig() call for each option, so parsing
is required to split the "-o string". This means that you will always
be affected by options separators interpretation. This is the reason
why I have suggested quoting.

I see a different issue (and I apologize for missing it in my previous
reply). mount(8) only supports quoting for named options, which means
using the format NAME="v,a,l,u,e". This is not expected if you do not
use NAME=, for example "/home/hostfs,dir".


I am not sure, but there may be another issue with your use-case. "-o
'/home/hostfs,dir'" means that "/home/hostfs,dir" will be used as the
key (variable name) in the fsconfig() syscall. I have doubts that it
is designed for long strings like paths. At first glance, kernel uses
only 256 bytes for the key (and since it is a variable without a
value, libmount will use it as FSCONFIG_SET_FLAG). 

Maybe Christian will know more details.

For now, my suggestion is to use the LIBMOUNT_FORCE_MOUNT2=always
environment variable to force mount(8) to use the classic mount(2)
syscall.

The long-term solution would be to clean up hostfs and use named
variables, such as "mount -t hostfs none -o 'path="/home/hostfs"'.

    Karel

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