linux-ext4 - Re: [PATCH v2] fs: ext4: support relative path for `journal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <728dd40e-a725-41c0-be90-a85e02d3cd76@huawei.com>
Date: Wed, 25 Sep 2024 16:01:34 +0800
From: Hongbo Li <lihongbo22@...wei.com>
To: Jan Kara <jack@...e.cz>
CC: <tytso@....edu>, <adilger.kernel@...ger.ca>, <viro@...iv.linux.org.uk>,
	<brauner@...nel.org>, <linux-ext4@...r.kernel.org>,
	<linux-fsdevel@...r.kernel.org>, <chris.zjh@...wei.com>
Subject: Re: [PATCH v2] fs: ext4: support relative path for `journal_path` in
 mount option.



On 2024/9/25 15:51, Jan Kara wrote:
> On Wed 25-09-24 09:56:24, Hongbo Li wrote:
>> The `fs_lookup_param` did not consider the relative path for
>> block device. When we mount ext4 with `journal_path` option using
>> relative path, `param->dirfd` was not set which will cause mounting
>> error.
>>
>> This can be reproduced easily like this:
>>
>> mke2fs -F -O journal_dev $JOURNAL_DEV -b 4096 100M
>> mkfs.ext4 -F -J device=$JOURNAL_DEV -b 4096 $FS_DEV
>> cd /dev; mount -t ext4 -o journal_path=`basename $JOURNAL_DEV` $FS_DEV $MNT
>>
>> Fixes: 461c3af045d3 ("ext4: Change handle_mount_opt() to use fs_parameter")
>> Suggested-by: Christian Brauner <brauner@...nel.org>
>> Signed-off-by: Hongbo Li <lihongbo22@...wei.com>
>> ---
>> v2:
>>    - Change the journal_path parameter as string not bdev, and
>>      determine the relative path situation inside fs_lookup_param.
>>    - Add Suggested-by.
>>
>> v1: https://lore.kernel.org/all/20240527-mahlen-packung-3fe035ab390d@brauner/
>> ---
>>   fs/ext4/super.c | 4 ++--
>>   fs/fs_parser.c  | 3 +++
>>   2 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
>> index 16a4ce704460..cd23536ce46e 100644
>> --- a/fs/ext4/super.c
>> +++ b/fs/ext4/super.c
>> @@ -1744,7 +1744,7 @@ static const struct fs_parameter_spec ext4_param_specs[] = {
>>   	fsparam_u32	("min_batch_time",	Opt_min_batch_time),
>>   	fsparam_u32	("max_batch_time",	Opt_max_batch_time),
>>   	fsparam_u32	("journal_dev",		Opt_journal_dev),
>> -	fsparam_bdev	("journal_path",	Opt_journal_path),
>> +	fsparam_string	("journal_path",	Opt_journal_path),
> 
> Why did you change this? As far as I can see the only effect would be that
> empty path will not be allowed (which makes sense) but that seems like an
> independent change which would deserve a comment in the changelog? Or am I
> missing something?

The fsparam_bdev serves no purpose here, you're right, empty path will 
not be allowed for `journal_path` option. And all changes are made to 
fix the issues (journal_path options changed) introduced by the previous 
new mount api conversion.

> 
>>   	fsparam_flag	("journal_checksum",	Opt_journal_checksum),
>>   	fsparam_flag	("nojournal_checksum",	Opt_nojournal_checksum),
>>   	fsparam_flag	("journal_async_commit",Opt_journal_async_commit),
>> @@ -2301,7 +2301,7 @@ static int ext4_parse_param(struct fs_context *fc, struct fs_parameter *param)
>>   			return -EINVAL;
>>   		}
>>   
>> -		error = fs_lookup_param(fc, param, 1, LOOKUP_FOLLOW, &path);
>> +		error = fs_lookup_param(fc, param, true, LOOKUP_FOLLOW, &path);
>>   		if (error) {
>>   			ext4_msg(NULL, KERN_ERR, "error: could not find "
>>   				 "journal device path");
>> diff --git a/fs/fs_parser.c b/fs/fs_parser.c
>> index 24727ec34e5a..2ae296764b69 100644
>> --- a/fs/fs_parser.c
>> +++ b/fs/fs_parser.c
>> @@ -156,6 +156,9 @@ int fs_lookup_param(struct fs_context *fc,
>>   		f = getname_kernel(param->string);
>>   		if (IS_ERR(f))
>>   			return PTR_ERR(f);
>> +		/* for relative path */
>> +		if (f->name[0] != '/')
>> +			param->dirfd = AT_FDCWD;
> 
> What Al meant is that you can do simply:
> 		param->dirfd = AT_FDCWD;
> 
> and everything will work the same because 'dfd' is ignored for absolute
> pathnames in path_init().
> 
ok, seems reasonable.

Thanks,
Hongbo
> 								Honza