Re: UML mount failure with Linux 6.11

[Johannes Berg <johannes@sipsolutions.net>]

Hi,

So took me a while to grok the context, and to understand why it was
working for me, and broken on another machine...


> I have read the context in [1]. It seems your tool has already used new 
> mount api to mount the hostfs.

Yes, however, that's a default that's entirely transparent to the user.
This is why I wasn't seeing the errors, depending on the machine I'm
running this on, because the 'mount' tool either uses the old or new
style and the user can never know.

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

And that's clearly the root cause of this regression.

You can't even argue it's not a regression, because before cd140ce9f611
("hostfs: convert hostfs to use the new mount API") it still worked with
the new fsconfig() API, but with the old mount options...

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

There's only one option anyway, so I'd think we just need to fix this
and not require the hostfs= key. Perhaps if and only if it starts with
hostfs= we can treat it as a key, otherwise treat it all as a dir? But I
guess the API wouldn't make that easy.

Anyway, I dunno, but it seems like a regression to me and we should try
to find a way to fix it.

johannes