On Mon, 2022-04-11 at 17:34 +0800, xiubli@xxxxxxxxxx wrote:
> From: Xiubo Li <xiubli@xxxxxxxxxx>
>
> From the posix and the initial statx supporting commit comments,
> the AT_STATX_DONT_SYNC is a lightweight stat flag and the
> AT_STATX_FORCE_SYNC is a heaverweight one. And also checked all
> the other current usage about these two flags they are all doing
> the same, that is only when the AT_STATX_FORCE_SYNC is not set
> and the AT_STATX_DONT_SYNC is set will they skip sync retriving
> the attributes from storage.
>
> Signed-off-by: Xiubo Li <xiubli@xxxxxxxxxx>
> ---
> fs/ceph/inode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c
> index 6788a1f88eb6..1ee6685def83 100644
> --- a/fs/ceph/inode.c
> +++ b/fs/ceph/inode.c
> @@ -2887,7 +2887,7 @@ int ceph_getattr(struct user_namespace *mnt_userns, const struct path *path,
> return -ESTALE;
>
> /* Skip the getattr altogether if we're asked not to sync */
> - if (!(flags & AT_STATX_DONT_SYNC)) {
> + if ((flags & AT_STATX_SYNC_TYPE) != AT_STATX_DONT_SYNC) {
> err = ceph_do_getattr(inode,
> statx_to_caps(request_mask, inode->i_mode),
> flags & AT_STATX_FORCE_SYNC);
I don't get it.
The only way I can see that this is a problem is if someone sent down a
mask with both DONT_SYNC and FORCE_SYNC set in it, and in that case I
don't see that ignoring FORCE_SYNC would be wrong...
--
Jeff Layton <jlayton@xxxxxxxxxx>
