From: Gao Xiang <hsiangkao@redhat.com>
To: Chao Yu <yuchao0@huawei.com>
Cc: cgxu <cgxu519@mykernel.net>, linux-erofs@lists.ozlabs.org
Subject: Re: [PATCH] erofs: code cleanup by removing ifdef macro surrounding
Date: Wed, 27 May 2020 10:16:28 +0800 [thread overview]
Message-ID: <20200527021628.GA10771@hsiangkao-HP-ZHAN-66-Pro-G1> (raw)
In-Reply-To: <451e6933-0465-6863-7972-999bd1cdf61f@huawei.com>
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...
Thanks,
Gao Xiang
>
>
> >
> > Thanks,
> > Gao Xiang
> >
> >>
> >>
> >> Thanks,
> >> cgxu
> >>
> >
> > .
> >
>
next prev parent reply other threads:[~2020-05-27 2:17 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 [this message]
2020-05-27 2:24 ` cgxu
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=20200527021628.GA10771@hsiangkao-HP-ZHAN-66-Pro-G1 \
--to=hsiangkao@redhat.com \
--cc=cgxu519@mykernel.net \
--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;
as well as URLs for NNTP newsgroup(s).