From: Hongbo Li <lihongbo22@huawei.com>
To: Johannes Berg <johannes@sipsolutions.net>, <rrs@debian.org>
Cc: <linux-um@lists.infradead.org>, <linux-fsdevel@vger.kernel.org>,
Christian Brauner <brauner@kernel.org>,
Benjamin Berg <benjamin@sipsolutions.net>
Subject: Re: UML mount failure with Linux 6.11
Date: Thu, 7 Nov 2024 22:17:07 +0800 [thread overview]
Message-ID: <f562158e-a113-4272-8be7-69b66a3ac343@huawei.com> (raw)
In-Reply-To: <420d651a262e62a15d28d9b28a8dbc503fec5677.camel@sipsolutions.net>
On 2024/11/7 21:09, Johannes Berg wrote:
> 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
May be we can do that (just record the unknown option in host_root_path
when fs_parse failed). But this lead us to consider the case in which we
should handle a long option -o unknown1,hostfs=xxx,unknow2, which one
should be treated as the root directory? For new mount api, it will call
fsconfig three times to set the root directory. For older one, if one
path with that name exactly, may be it can mount successfully.
Thanks,
Hongbo
> 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
>
next prev parent reply other threads:[~2024-11-07 14:17 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-30 8:13 UML mount failure with Linux 6.11 Ritesh Raj Sarraf
2024-10-31 10:07 ` Benjamin Berg
2024-11-06 11:52 ` Ritesh Raj Sarraf
2024-11-06 19:25 ` Benjamin Berg
2024-11-07 6:22 ` Hongbo Li
2024-11-07 13:09 ` Johannes Berg
2024-11-07 14:17 ` Hongbo Li [this message]
2024-11-07 14:35 ` Johannes Berg
2024-11-11 1:16 ` Hongbo Li
2024-11-12 20:10 ` Karel Zak
2024-11-13 1:23 ` Hongbo Li
2024-11-21 13:53 ` Hongbo Li
2024-11-25 17:43 ` Karel Zak
2024-11-26 13:50 ` Johannes Berg
2024-11-27 1:26 ` Hongbo Li
2024-11-27 12:02 ` Karel Zak
2024-11-27 13:15 ` Johannes Berg
2024-11-28 10:58 ` Karel Zak
2024-11-28 12:55 ` Johannes Berg
2024-11-27 13:55 ` Hongbo Li
2024-11-27 11:55 ` Karel Zak
2024-11-27 12:16 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f562158e-a113-4272-8be7-69b66a3ac343@huawei.com \
--to=lihongbo22@huawei.com \
--cc=benjamin@sipsolutions.net \
--cc=brauner@kernel.org \
--cc=johannes@sipsolutions.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=rrs@debian.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox