[PATCH] erofs: reject unknown option if it is not supported

Hongbo Li lihongbo22 at huawei.com
Tue Apr 29 13:46:39 AEST 2025



On 2025/4/28 23:16, Gao Xiang wrote:
> On Mon, Apr 28, 2025 at 02:25:45PM +0000, Hongbo Li wrote:
>> Some options are supported depending on different compiling config,
>> and these option will not fail during mount if they are not
>> supported. This is very weird, so we can reject them if they are
>> not supported.
>>
> 
> If it's an invalid option, we should reject it immediately.
> 
> But for unsupported options, I don't think we always error
> out. e.g. for some options like (acl, noacl) ext4 will just
> ignore if ACL is unsupported.
> 
Thanks for reviewing!
I will keep this in later version.

> I think EROFS should follows that, otherwise users might use
> "noacl" to disable ACL explicitly, but it will fail unexpectedly
> if unsupported.
> 
> But I agree that for "fsid", "domain_id" and "directio", we
> could error out instead.
> 
>> Signed-off-by: Hongbo Li <lihongbo22 at huawei.com>
>> ---
>>   fs/erofs/super.c | 39 ++++++++++++++++++---------------------
>>   1 file changed, 18 insertions(+), 21 deletions(-)
>>
>> diff --git a/fs/erofs/super.c b/fs/erofs/super.c
>> index cadec6b1b554..c1c350c6fbf4 100644
>> --- a/fs/erofs/super.c
>> +++ b/fs/erofs/super.c
>> @@ -374,16 +374,26 @@ static const struct constant_table erofs_dax_param_enums[] = {
>>   };
>>   
>>   static const struct fs_parameter_spec erofs_fs_parameters[] = {
>> +#ifdef CONFIG_EROFS_FS_XATTR
>>   	fsparam_flag_no("user_xattr",	Opt_user_xattr),
>> +#endif
> 
> Another thing is that I'm not sure if "user_xattr" option is really
> needed, we might just kill this option since all recent fses don't
> have such configuration and user_xattrs should be supported by default.
> 
Yeah, perhaps this option should be removed along with 
CONFIG_EROFS_FS_XATTR, as xattr can be also consider as a type of data 
that we cannot modify.

Thanks,
Hongbo

> Thanks,
> Gao Xiang
> 


More information about the Linux-erofs mailing list