From: Christian Brauner <brauner@kernel.org>
To: Hongbo Li <lihongbo22@huawei.com>
Cc: viro@zeniv.linux.org.uk, jack@suse.cz, tytso@mit.edu,
adilger.kernel@dilger.ca, lczerner@redhat.com,
cmaiolino@redhat.com, linux-fsdevel@vger.kernel.org,
linux-doc@vger.kernel.org, yi.zhang@huawei.com
Subject: Re: [PATCH v2 3/4] fs: ext4: support relative path for `journal_path` in mount option.
Date: Mon, 27 May 2024 17:39:57 +0200 [thread overview]
Message-ID: <20240527-mahlen-packung-3fe035ab390d@brauner> (raw)
In-Reply-To: <20240527075854.1260981-4-lihongbo22@huawei.com>
On Mon, May 27, 2024 at 03:58:53PM +0800, Hongbo Li wrote:
> After `fs_param_is_blockdev` is implemented(in fs: add blockdev parser
> for filesystem mount option.), `journal_devnum` can be obtained from
> `result.uint_32` directly.
>
> Additionally, 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.
That's a failure in userspace though. If a relative pathname is provided
then AT_FDCWD or a valid file descriptor must be provided:
fsconfig(fd_fs, FSCONFIG_SET_PATH, "journal_path", "relative/path", AT_FDCWD);
But if you're seeing this from mount(8) then util-linux very likely
does (cf. [1]):
fsconfig(fd_fs, FSCONFIG_SET_STRING, "journal_path", "relative/path", 0);
So mount(8) is passing that as a string as it has no way to figure out
that this should be passed as FSCONFIG_SET_PATH. So to allow relative
paths in string options we'd need something (untested) like:
diff --git a/fs/fs_parser.c b/fs/fs_parser.c
index a4d6ca0b8971..18ca40408e91 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);
+ /* relative path */
+ if (*f->name[0] != '/')
+ param->dirfd = AT_FDCWD;
put_f = true;
break;
case fs_value_is_filename:
https://github.com/util-linux/util-linux/blob/55ca447a6a95226fd031a126fb48b01b3efd6284/libmount/src/hook_mount.c#L178
>
> 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")
> Signed-off-by: Hongbo Li <lihongbo22@huawei.com>
> ---
> fs/ext4/super.c | 26 +-------------------------
> 1 file changed, 1 insertion(+), 25 deletions(-)
>
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index c682fb927b64..94b39bcae99d 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -2290,39 +2290,15 @@ static int ext4_parse_param(struct fs_context *fc, struct fs_parameter *param)
> ctx->spec |= EXT4_SPEC_s_resgid;
> return 0;
> case Opt_journal_dev:
> - if (is_remount) {
> - ext4_msg(NULL, KERN_ERR,
> - "Cannot specify journal on remount");
> - return -EINVAL;
> - }
> - ctx->journal_devnum = result.uint_32;
> - ctx->spec |= EXT4_SPEC_JOURNAL_DEV;
> - return 0;
> case Opt_journal_path:
> - {
> - struct inode *journal_inode;
> - struct path path;
> - int error;
> -
> if (is_remount) {
> ext4_msg(NULL, KERN_ERR,
> "Cannot specify journal on remount");
> return -EINVAL;
> }
This would cause a path lookup in the VFS layer only to immediately
reject it on remount.
next prev parent reply other threads:[~2024-05-27 15:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-27 7:58 [PATCH v2 0/4] enhance the path resolution capability in fs_parser Hongbo Li
2024-05-27 7:58 ` [PATCH v2 1/4] fs: add blockdev parser for filesystem mount option Hongbo Li
2024-05-27 7:58 ` [PATCH v2 2/4] fs: add path " Hongbo Li
2024-05-27 14:32 ` Christian Brauner
2024-05-27 16:26 ` Christoph Hellwig
2024-05-27 7:58 ` [PATCH v2 3/4] fs: ext4: support relative path for `journal_path` in " Hongbo Li
2024-05-27 15:39 ` Christian Brauner [this message]
2024-05-27 7:58 ` [PATCH v2 4/4] fs: remove fs_lookup_param and its description Hongbo Li
2024-05-27 15:08 ` [PATCH v2 0/4] enhance the path resolution capability in fs_parser 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=20240527-mahlen-packung-3fe035ab390d@brauner \
--to=brauner@kernel.org \
--cc=adilger.kernel@dilger.ca \
--cc=cmaiolino@redhat.com \
--cc=jack@suse.cz \
--cc=lczerner@redhat.com \
--cc=lihongbo22@huawei.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
--cc=yi.zhang@huawei.com \
/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;
as well as URLs for NNTP newsgroup(s).