linux-um archives
 help / color / mirror / Atom feed
From: Hongbo Li <lihongbo22@huawei.com>
To: Karel Zak <kzak@redhat.com>
Cc: <linux-um@lists.infradead.org>, <linux-fsdevel@vger.kernel.org>,
	Christian Brauner <brauner@kernel.org>,
	Benjamin Berg <benjamin@sipsolutions.net>,
	Johannes Berg <johannes@sipsolutions.net>, <rrs@debian.org>
Subject: Re: UML mount failure with Linux 6.11
Date: Thu, 21 Nov 2024 21:53:06 +0800	[thread overview]
Message-ID: <3d5e772c-7f13-4557-82ff-73e29a501466@huawei.com> (raw)
In-Reply-To: <9f56df34-68d4-4cb1-9b47-b8669b16ed28@huawei.com>



On 2024/11/13 9:23, Hongbo Li wrote:
> 
> 
> On 2024/11/13 4:10, Karel Zak wrote:
>>
>>   Hi,
>>
>> On Mon, Nov 11, 2024 at 09:16:18AM GMT, Hongbo Li wrote:
>>> We are discussing about the hostfs mount with new mount API in [1]. 
>>> And may
>>> need your help.
>>>
>>> After finishing the conversion to the new mount API for hostfs, it
>>> encountered a situation where the old version supported only one mount
>>> option, and the whole mount option was used as the root path (it is also
>>> valid for the path to contain commas). But when switching to the new 
>>> mount
>>> API, the option part will be split using commas (if I'm not mistaken, 
>>> this
>>> step would be done in libmount), which could potentially split a 
>>> complete
>>> path into multiple parts, and the call fsconfig syscall to set the mount
>>> options for underline filesystems. This is different from the original
>>> intention of hostfs. And this kind of situation is not common in other
>>> filesystems.
>>
>> 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?

Thanks,
Hongbo

> 
> Thanks,
> Hongbo
> 
>>     mount -o 'rw,bbb="this,is,value",ccc'
>>
>> It's also supported in fstab, just use name="v,a,l,u,e"
>>
>> You can try it:
>>
>>   # strace -e fsconfig mount -t tmpfs -o 'rw,bbb="this,is,value",ccc' 
>> tmpfs /dontexist
>>
>>   fsconfig(3, FSCONFIG_SET_STRING, "source", "tmpfs", 0) = 0
>>   fsconfig(3, FSCONFIG_SET_FLAG, "rw", NULL, 0) = 0
>>   fsconfig(3, FSCONFIG_SET_STRING, "bbb", "this,is,value", 0) = -1 EINVAL
>>
>> You can see the expected result when using fsconfig().
>>
>>   Karel
>>
>>
> 
> 


  reply	other threads:[~2024-11-21 13:53 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
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 [this message]
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=3d5e772c-7f13-4557-82ff-73e29a501466@huawei.com \
    --to=lihongbo22@huawei.com \
    --cc=benjamin@sipsolutions.net \
    --cc=brauner@kernel.org \
    --cc=johannes@sipsolutions.net \
    --cc=kzak@redhat.com \
    --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