From: cgxu <cgxu519@mykernel.net>
To: Gao Xiang <hsiangkao@redhat.com>, Chao Yu <yuchao0@huawei.com>
Cc: linux-erofs@lists.ozlabs.org
Subject: Re: [PATCH] erofs: code cleanup by removing ifdef macro surrounding
Date: Wed, 27 May 2020 10:24:14 +0800 [thread overview]
Message-ID: <5d650808-e326-142c-048b-2c574741cd96@mykernel.net> (raw)
In-Reply-To: <20200527021628.GA10771@hsiangkao-HP-ZHAN-66-Pro-G1>
On 5/27/20 10:16 AM, Gao Xiang wrote:
> On Wed, May 27, 2020 at 09:55:17AM +0800, Chao Yu wrote:
>
> ...
>
>>>>
>>>> Originally, we set erofs_listxattr to ->listxattr only
>>>> when the config macro CONFIG_EROFS_FS_XATTR is enabled,
>>>> it means that erofs_listxattr() never returns -EOPNOTSUPP
>>>> in any case, so actually there is no logic change here,
>>>> right?
>>>
>>> Yeah, I agree there is no logic change, so I'm fine with the patch.
>>> But I'm little worry about if return 0 is actually wrong here...
>>>
>>> see the return value at:
>>> http://man7.org/linux/man-pages/man2/listxattr.2.html
>>
>> Yeah, I guess vfs should check that whether lower filesystem has set .listxattr
>> callback function to decide to return that value, something like:
>>
>> static ssize_t
>> ecryptfs_listxattr(struct dentry *dentry, char *list, size_t size)
>> {
>> ...
>> if (!d_inode(lower_dentry)->i_op->listxattr) {
>> rc = -EOPNOTSUPP;
>> goto out;
>> }
>> ...
>> rc = d_inode(lower_dentry)->i_op->listxattr(lower_dentry, list, size);
>> ...
>> }
>
> This approach seems better. ;) Let me recheck all of this.
> Maybe we could submit a patch to fsdevel for some further advice...
>
I agree that doing the check in vfs layer looks tidy and unified.
However, we should be aware this change may break user space tools.
Thanks,
cgxu
next prev parent reply other threads:[~2020-05-27 2:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-26 9:03 [PATCH] erofs: code cleanup by removing ifdef macro surrounding Chengguang Xu
2020-05-26 9:49 ` Gao Xiang
2020-05-26 10:29 ` cgxu
2020-05-26 10:35 ` Gao Xiang
2020-05-27 1:55 ` Chao Yu
2020-05-27 2:16 ` Gao Xiang
2020-05-27 2:24 ` cgxu [this message]
2020-05-27 2:35 ` 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=5d650808-e326-142c-048b-2c574741cd96@mykernel.net \
--to=cgxu519@mykernel.net \
--cc=hsiangkao@redhat.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=yuchao0@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