UML mount failure with Linux 6.11

[Hongbo Li]

Hi Ritesh and Benjamin,

I have read the context in [1]. It seems your tool has already used new 
mount api to mount the hostfs. It now rejects unknown mount options as 
many other filesystems do regardless of its earlier behavior (which 
treats any option as the root directory in hostfs).

This should be clarified for unknown option. For older hostfs (before 
new mount api), it treats the whole string behind -o as the root 
directory. This will allow any mount options, but also limit its 
extension. It is not the same as other mainline filesystems which will 
split the option string with ','. So for these filesystems, they can 
consider whether reject unknown mount options or not.

I'm not sure it is reasonable in this way. If we accept unknown option 
in the hostfs, it will be treated as root directory. But which one 
should be used (like mount -t hostfs -o unknown,/root/directory none 
/mnt). So in the conversion, we introduce the `hostfs` key to mark the 
root directory. May be we need more discussion about use case.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086194


Thanks,
Hongbo

On 2024/11/7 3:25, Benjamin Berg wrote:
> Hi,
> 
> I am probably not the right person to talk to. Maybe Hongbo Li can say
> more?
> 
> That said, it looks like the filesystem now has the "hostfs" option. So
> you can probably just use
>    mount -t hostfs -o hostfs=/path none /mount/point
> which is nicer anyway. Just a bit annoying as you probably need to pass
> it differently for older kernels.
> 
> Benjamin
> 
> On Wed, 2024-11-06 at 17:22 +0530, Ritesh Raj Sarraf wrote:
>> Hello Benjamin,
>>
>> On Thu, 2024-10-31 at 11:07 +0100, Benjamin Berg wrote:
>>> Hi,
>>>
>>> Newer kernels have become more picky about that with the new mount
>>> API.
>>> This is relevant, see the discussion about "Unknown options":
>>>    https://lwn.net/Articles/979166/
>>>
>>> We only use hostfs for the root file system and in that case it
>>> works
>>> well if you pass the path using "hostfs=/path" on the kernel
>>> command
>>> line. Doing that avoids issues when remounting the file system
>>> later
>>> on.
>>>
>>
>> As upstream developers for UML, what would you conclude it as ?
>>
>> We've recommended using hostfs for the UML kernel modules as well.
>> What
>> would be the alternate approach to ensuring a proper boot for a
>> modular
>> UML kernel ?
>>
>>
>>> I suppose that currently it does not work to mount hostfs later on.
>>> No
>>> idea what the right fix is. Maybe the host directory should be an
>>> explicit option like "hostpath=..." or so to make it compatible
>>> with
>>> the new mount APIs.
>>
>> The ability to mount any hostfs mount point was/is a feature provided
>> by UML. We've used it and integrated with many tools like debos,
>> fakemachine etc; the Debian bug report has the details.
>>
>> There'll be more reports following once UML 6.11 hits Debian Testing.
>>
>> I hadn't expected a working feature to break with a newer Linux
>> release. :-(
>>
>> Thanks,
>> Ritesh
>>
> 
>