Linux EXT4 FS development
 help / color / mirror / Atom feed
From: Hongbo Li <lihongbo22@huawei.com>
To: Jan Kara <jack@suse.cz>
Cc: <tytso@mit.edu>, <adilger.kernel@dilger.ca>,
	<viro@zeniv.linux.org.uk>, <brauner@kernel.org>,
	<linux-ext4@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
	<chris.zjh@huawei.com>
Subject: Re: [PATCH v2] fs: ext4: support relative path for `journal_path` in mount option.
Date: Wed, 25 Sep 2024 16:01:34 +0800	[thread overview]
Message-ID: <728dd40e-a725-41c0-be90-a85e02d3cd76@huawei.com> (raw)
In-Reply-To: <20240925075105.lnssx7gcgfh5s743@quack3>



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@kernel.org>
>> Signed-off-by: Hongbo Li <lihongbo22@huawei.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

  reply	other threads:[~2024-09-25  8:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-25  1:56 [PATCH v2] fs: ext4: support relative path for `journal_path` in mount option Hongbo Li
2024-09-25  2:09 ` Al Viro
2024-09-25  2:32   ` Hongbo Li
2024-09-25  7:51 ` Jan Kara
2024-09-25  8:01   ` Hongbo Li [this message]
2024-09-25  8:21   ` Christian Brauner
2024-09-25  8:24 ` Christian Brauner

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=728dd40e-a725-41c0-be90-a85e02d3cd76@huawei.com \
    --to=lihongbo22@huawei.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=brauner@kernel.org \
    --cc=chris.zjh@huawei.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /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