Message-ID: <96170678-b302-4990-b229-b30d96e39806@huawei.com>
Date: Fri, 26 Jul 2024 16:36:39 +0800
From: Hongbo Li <lihongbo22@...wei.com>
To: Christian Brauner <brauner@...nel.org>
CC: Maciej Żenczykowski <maze@...gle.com>, Matthew Wilcox
	<willy@...radead.org>, Kernel hackers <linux-kernel@...r.kernel.org>, Patrick
 Rohr <prohr@...gle.com>, Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: UML/hostfs - mount failure at tip of tree



On 2024/7/26 15:52, Christian Brauner wrote:
> On Wed, Jul 24, 2024 at 05:49:16PM GMT, Hongbo Li wrote:
>>
>>
>> On 2024/7/24 11:59, Maciej Żenczykowski wrote:
>>> On Tue, Jul 23, 2024 at 7:55 PM Maciej Żenczykowski <maze@...gle.com> wrote:
>>>>
>>>> On Tue, Jul 23, 2024 at 7:22 PM Linus Torvalds
>>>> <torvalds@...ux-foundation.org> wrote:
>>>>>
>>>>> On Tue, 23 Jul 2024 at 18:35, Hongbo Li <lihongbo22@...wei.com> wrote:
>>>>>>
>>>>>> I apologize for causing this issue. I am currently tracking it down.  If
>>>>>> reverting this can solve the problem, you can revert it first.
>>>>>
>>>>> I don't get the feeling that this is _so_ urgent that it needs to be
>>>>> reverted immediately - let's give it at least a few days and see if
>>>>> you (or somebody else) figures out the bug.
>>>>>
>>>>> Maciej - if you can verify that folio conversion fix suggestion of
>>>>> mine (or alternatively report that it doesn't help and I was barking
>>>>> up the wrong tree), that would be great.
>>>>
>>>> That appears to fix the folio patch indeed (ie. I no longer need to revert it).
>>>>
>>>> The tests are still super unhappy, but I've yet to fix our tests very
>>>> broken netlink parser for changes that released in 6.10, so that may
>>>> be unrelated ;-)
>>>
>>> +++ fs/hostfs/hostfs_kern.c:
>>>    static int hostfs_fill_super(struct super_block *sb, struct fs_context *fc)
>>>    {
>>>           struct hostfs_fs_info *fsi = sb->s_fs_info;
>>> -       const char *host_root = fc->source;
>>> +       const char *host_root = "/";
>>>
>> This doesn't work in case where the host directory is designated (such as
>> mount -t hostfs hostfs -o /home /host).
>>
>> I can fix this by the following patch, the root cause of this issue is the
>> incorrect parsing of the host directory. The original mount path will use
>> `parse_monolithic` to parse the host directory. For the new mount api, it
>> use `parse_param` directly. So we should call `fsconfig(fd,
>> FSCONFIG_SET_STRING, "hostfs", "xxx", 0)` to mount the hostfs(I think may be
>> we should add hostfs as the key for host directory.). This may need
>> Christian's reviews.:
>>
>> ```
>>  From e7cc3be86a01b8382e9510f6ae1a2764942c7cba Mon Sep 17 00:00:00 2001
>> From: Hongbo Li <lihongbo22@...wei.com>
>> Date: Wed, 24 Jul 2024 16:08:32 +0800
>> Subject: [PATCH] hostfs: fix the host directory parse when mounting.
>>
>> hostfs not keep the host directory when mounting. When the host
>> directory is none (default), fc->source is used as the host root
>> directory, and this is wrong. Here we use `parse_monolithic` to
>> handle the old mount path for parsing the root directory. For new
>> mount path, The `parse_param` is used for the host directory parse.
>>
>> Fixes: cd140ce9f611 ("hostfs: convert hostfs to use the new mount API")
>> Signed-off-by: Hongbo Li <lihongbo22@...wei.com>
>> ---
>>   fs/hostfs/hostfs_kern.c | 64 ++++++++++++++++++++++++++++++++++-------
>>   1 file changed, 54 insertions(+), 10 deletions(-)
>>
>> diff --git a/fs/hostfs/hostfs_kern.c b/fs/hostfs/hostfs_kern.c
>> index 3eb747d26924..205c3700a035 100644
>> --- a/fs/hostfs/hostfs_kern.c
>> +++ b/fs/hostfs/hostfs_kern.c
>> @@ -17,6 +17,7 @@
>>   #include <linux/writeback.h>
>>   #include <linux/mount.h>
>>   #include <linux/fs_context.h>
>> +#include <linux/fs_parser.h>
>>   #include <linux/namei.h>
>>   #include "hostfs.h"
>>   #include <init.h>
>> @@ -927,7 +928,6 @@ static const struct inode_operations hostfs_link_iops =
>> {
>>   static int hostfs_fill_super(struct super_block *sb, struct fs_context *fc)
>>   {
>>   	struct hostfs_fs_info *fsi = sb->s_fs_info;
>> -	const char *host_root = fc->source;
>>   	struct inode *root_inode;
>>   	int err;
>>
>> @@ -941,15 +941,6 @@ static int hostfs_fill_super(struct super_block *sb,
>> struct fs_context *fc)
>>   	if (err)
>>   		return err;
>>
>> -	/* NULL is printed as '(null)' by printf(): avoid that. */
>> -	if (fc->source == NULL)
>> -		host_root = "";
>> -
>> -	fsi->host_root_path =
>> -		kasprintf(GFP_KERNEL, "%s/%s", root_ino, host_root);
>> -	if (fsi->host_root_path == NULL)
>> -		return -ENOMEM;
>> -
>>   	root_inode = hostfs_iget(sb, fsi->host_root_path);
>>   	if (IS_ERR(root_inode))
>>   		return PTR_ERR(root_inode);
>> @@ -975,6 +966,57 @@ static int hostfs_fill_super(struct super_block *sb,
>> struct fs_context *fc)
>>   	return 0;
>>   }
>>
>> +enum hostfs_parma {
>> +	Opt_hostfs,
>> +};
>> +
>> +static const struct fs_parameter_spec hostfs_param_specs[] = {
>> +	fsparam_string_empty("hostfs",		Opt_hostfs),
>> +	{}
>> +};
>> +
>> +static int hostfs_parse_param(struct fs_context *fc, struct fs_parameter
>> *param)
>> +{
>> +	struct hostfs_fs_info *fsi = fc->s_fs_info;
>> +	struct fs_parse_result result;
>> +	char *host_root;
>> +	int opt;
>> +
>> +	opt = fs_parse(fc, hostfs_param_specs, param, &result);
>> +	if (opt < 0)
>> +		return opt;
>> +
>> +	switch (opt) {
>> +	case Opt_hostfs:
>> +		host_root = param->string;
>> +		if (!host_root)
>> +			host_root = "";
> 
> That should be:
> 
> host_root = param->string;
> if (!*host_root)
> 	host_root = "";
> 
> as param->string is never NULL but can be an empty string. I'll fix that
> up though.
> 
Thanks for reviewing!
Yeah, param->string is checked at the begin of fsconfig syscall, here is 
just for double check (may be redundant). The empty string is allowed 
for host_root(also ""), or just remove this?

Thanks,
Hongbo

> Otherwise overall looks sane to me.
> 
> I'm a bit puzzled that hostfs allowed to specify an option without a key like:
> 
> mount("hostfs", "/mnt", "/home");
> 
> but ok. So in the new mount api you did:
> 
> fsconfig(fd, FSCONFIG_SET_STRING, "hostfs", "/home", 0);
> 
> which I think is a lot saner.
> 
>> +		fsi->host_root_path =
>> +			kasprintf(GFP_KERNEL, "%s/%s", root_ino, host_root);
>> +		if (fsi->host_root_path == NULL)
>> +			return -ENOMEM;
>> +		break;
>> +	}
>> +
>> +	return 0;
>> +}
>> +static int hostfs_parse_monolithic(struct fs_context *fc, void *data)
>> +{
>> +	struct hostfs_fs_info *fsi = fc->s_fs_info;
>> +	char *host_root = (char *)data;
>> +
>> +	/* NULL is printed as '(null)' by printf(): avoid that. */
>> +	if (host_root == NULL)
>> +		host_root = "";
>> +
>> +	fsi->host_root_path =
>> +		kasprintf(GFP_KERNEL, "%s/%s", root_ino, host_root);
>> +	if (fsi->host_root_path == NULL)
>> +		return -ENOMEM;
>> +
>> +	return 0;
>> +}
>> +
>>   static int hostfs_fc_get_tree(struct fs_context *fc)
>>   {
>>   	return get_tree_nodev(fc, hostfs_fill_super);
>> @@ -992,6 +1034,8 @@ static void hostfs_fc_free(struct fs_context *fc)
>>   }
>>
>>   static const struct fs_context_operations hostfs_context_ops = {
>> +	.parse_monolithic = hostfs_parse_monolithic,
>> +	.parse_param	= hostfs_parse_param,
>>   	.get_tree	= hostfs_fc_get_tree,
>>   	.free		= hostfs_fc_free,
>>   };
>> -- 
>> 2.34.1
>> ```
>>
>> Thanks,
>> Hongbo
>>
>>> appears to fix the problem (when combined with Linus' folio fix).
>>>
>>> I think fc->source is just the 'block device' passed to mount, and
>>> thus for a virtual filesystem like hostfs, it is just garbage...
>>>
>>> (and with the appropriate netlink fixes all the tests now pass at tip-of-tree:
>>> 87f3073c2871 (HEAD) hostfs_fill_super(): host_root := "/" (not fc->source)
>>> 2743a4aabac6 fs/hostfs/hostfs_kern.c:445 buffer =
>>> folio_zero_tail(folio, bytes_read, buffer + bytes_read);
>>> a2caf678d7e1 neighbour: add RTNL_FLAG_DUMP_SPLIT_NLM_DONE to RTM_GETNEIGH
>>> 3bb0c5772acf net: add RTNL_FLAG_DUMP_SPLIT_NLM_DONE to RTM_GET(RULE|ROUTE)
>>> 786c8248dbd3 (linux/master) Merge tag
>>> 'perf-tools-fixes-for-v6.11-2024-07-23' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools
>>> )
>>>
>>>>> And perhaps remind me about this mount API thing too if it doesn't
>>>>> seem to be resolved by the end of the week when I'm starting to get
>>>>> ready to do the rc1?
>>>>>
>>>>>                Linus
>>>>
>>>> --
>>>> Maciej Żenczykowski, Kernel Networking Developer @ Google
>>>
>>> --
>>> Maciej Żenczykowski, Kernel Networking Developer @ Google
>>>

Powered by blists - more mailing lists