From: Ian Kent <raven@themaw.net>
To: Chen Linxuan <chenlinxuan@uniontech.com>,
Gao Xiang <xiang@kernel.org>, Chao Yu <chao@kernel.org>,
Yue Hu <zbestahu@gmail.com>,
Jeffle Xu <jefflexu@linux.alibaba.com>,
Sandeep Dhavale <dhavale@google.com>
Cc: linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] erofs: add error log in erofs_fc_parse_param
Date: Sat, 18 Jan 2025 08:45:13 +0800 [thread overview]
Message-ID: <9b2b5a34-cddd-41b2-9d1e-939b9f97b44b@themaw.net> (raw)
In-Reply-To: <F2F43EB045D266E8+20250117085244.326177-1-chenlinxuan@uniontech.com>
On 17/1/25 16:52, Chen Linxuan wrote:
> While reading erofs code, I notice that `erofs_fc_parse_param` will
> return -ENOPARAM, which means that erofs do not support this option,
> without report anything when `fs_parse` return an unknown `opt`.
>
> But if an option is unknown to erofs, I mean that option not in
> `erofs_fs_parameters` at all, `fs_parse` will return -ENOPARAM,
> which means that `erofs_fs_parameters` should has returned earlier.
I'm pretty sure than the vfs deals with reporting unknown options
and returns -EINVAL already.
I think the caller oferofs_fc_parse_param() is vfs_parse_fs_param()
and for an -ENOPARAM return will ultimately do this:
return invalf(fc, "%s: Unknown parameter '%s'", fc->fs_type->name,
param->key);
which does this.
The thing about this is the mount API macro deals with (or it should,
although I'm not sure that's completely sorted out yet) logging the
message to the console log as well as possibly making it available to
mount api system calls. I'm pretty sure this change will prevent the
error message being available for mount api system calls to retrieve.
Ian
>
> Entering `default` means `fs_parse` return something we unexpected.
> I am not sure about it but I think we should return -EINVAL here,
> just like `xfs_fs_parse_param`.
>
> Signed-off-by: Chen Linxuan <chenlinxuan@uniontech.com>
> ---
> fs/erofs/super.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/erofs/super.c b/fs/erofs/super.c
> index 1fc5623c3a4d..67fc4c1deb98 100644
> --- a/fs/erofs/super.c
> +++ b/fs/erofs/super.c
> @@ -509,7 +509,8 @@ static int erofs_fc_parse_param(struct fs_context *fc,
> #endif
> break;
> default:
> - return -ENOPARAM;
> + errorfc(fc, "%s option not supported", param->key);
> + return -EINVAL;
> }
> return 0;
> }
next prev parent reply other threads:[~2025-01-18 0:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-17 8:52 Chen Linxuan
2025-01-17 9:28 ` Gao Xiang
2025-01-17 9:50 ` Chen Linxuan
2025-01-17 9:54 ` Gao Xiang
2025-01-17 10:00 ` Chen Linxuan
2025-01-17 10:08 ` Gao Xiang
2025-01-17 10:01 ` Chen Linxuan
2025-01-18 0:45 ` Ian Kent [this message]
2025-01-18 1:25 ` Ian Kent
2025-01-18 8:45 ` Gao Xiang
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=9b2b5a34-cddd-41b2-9d1e-939b9f97b44b@themaw.net \
--to=raven@themaw.net \
--cc=chao@kernel.org \
--cc=chenlinxuan@uniontech.com \
--cc=dhavale@google.com \
--cc=jefflexu@linux.alibaba.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=xiang@kernel.org \
--cc=zbestahu@gmail.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
all inboxes | Powered by JetHome®