From: Dan Carpenter <dan.carpenter@oracle.com>
To: trond.myklebust@primarydata.com
Cc: linux-nfs@vger.kernel.org
Subject: [bug report] NFS: Split attribute support out from the server capabilities
Date: Wed, 21 Apr 2021 11:53:58 +0300 [thread overview]
Message-ID: <YH/oJpIhnG9aC5Cs@mwanda> (raw)
Hello Trond Myklebust,
The patch ce62b114bbad: "NFS: Split attribute support out from the
server capabilities" from Mar 5, 2018, leads to the following static
checker warning:
fs/nfs/nfs4proc.c:3882 _nfs4_server_capabilities() warn: was expecting a 64 bit value instead of '(1 << 11)'
fs/nfs/nfs4proc.c:3884 _nfs4_server_capabilities() warn: was expecting a 64 bit value instead of '(1 << 1)'
fs/nfs/nfs4proc.c:3886 _nfs4_server_capabilities() warn: was expecting a 64 bit value instead of '(1 << 2)'
fs/nfs/nfs4proc.c:3889 _nfs4_server_capabilities() warn: was expecting a 64 bit value instead of '((1 << 3) | (1 << 23))'
fs/nfs/nfs4proc.c:3892 _nfs4_server_capabilities() warn: was expecting a 64 bit value instead of '((1 << 4) | (1 << 24))'
fs/nfs/nfs4proc.c:3894 _nfs4_server_capabilities() warn: was expecting a 64 bit value instead of '(1 << 9)'
fs/nfs/nfs4proc.c:3896 _nfs4_server_capabilities() warn: was expecting a 64 bit value instead of '(1 << 12)'
fs/nfs/nfs4proc.c:3898 _nfs4_server_capabilities() warn: was expecting a 64 bit value instead of '(1 << 14)'
fs/nfs/nfs4proc.c:3900 _nfs4_server_capabilities() warn: was expecting a 64 bit value instead of '(1 << 13)'
fs/nfs/nfs4proc.c:3903 _nfs4_server_capabilities() warn: was expecting a 64 bit value instead of '(1 << 25)'
fs/nfs/nfs4proc.c
3869 }
3870 memcpy(server->attr_bitmask, res.attr_bitmask, sizeof(server->attr_bitmask));
3871 server->caps &= ~(NFS_CAP_ACLS | NFS_CAP_HARDLINKS |
3872 NFS_CAP_SYMLINKS| NFS_CAP_SECURITY_LABEL);
3873 server->fattr_valid = NFS_ATTR_FATTR_V4;
3874 if (res.attr_bitmask[0] & FATTR4_WORD0_ACL &&
3875 res.acl_bitmask & ACL4_SUPPORT_ALLOW_ACL)
3876 server->caps |= NFS_CAP_ACLS;
3877 if (res.has_links != 0)
3878 server->caps |= NFS_CAP_HARDLINKS;
3879 if (res.has_symlinks != 0)
3880 server->caps |= NFS_CAP_SYMLINKS;
3881 if (!(res.attr_bitmask[0] & FATTR4_WORD0_FILEID))
3882 server->fattr_valid &= ~NFS_ATTR_FATTR_FILEID;
->fattr_valid is a u64 but ~NFS_ATTR_FATTR_FILEID is a u32. This code
is supposed to clear the NFS_ATTR_FATTR_FILEID bit, but it clears all
high 32 bits as well.
3883 if (!(res.attr_bitmask[1] & FATTR4_WORD1_MODE))
3884 server->fattr_valid &= ~NFS_ATTR_FATTR_MODE;
3885 if (!(res.attr_bitmask[1] & FATTR4_WORD1_NUMLINKS))
3886 server->fattr_valid &= ~NFS_ATTR_FATTR_NLINK;
3887 if (!(res.attr_bitmask[1] & FATTR4_WORD1_OWNER))
3888 server->fattr_valid &= ~(NFS_ATTR_FATTR_OWNER |
3889 NFS_ATTR_FATTR_OWNER_NAME);
3890 if (!(res.attr_bitmask[1] & FATTR4_WORD1_OWNER_GROUP))
3891 server->fattr_valid &= ~(NFS_ATTR_FATTR_GROUP |
3892 NFS_ATTR_FATTR_GROUP_NAME);
3893 if (!(res.attr_bitmask[1] & FATTR4_WORD1_SPACE_USED))
3894 server->fattr_valid &= ~NFS_ATTR_FATTR_SPACE_USED;
3895 if (!(res.attr_bitmask[1] & FATTR4_WORD1_TIME_ACCESS))
3896 server->fattr_valid &= ~NFS_ATTR_FATTR_ATIME;
3897 if (!(res.attr_bitmask[1] & FATTR4_WORD1_TIME_METADATA))
3898 server->fattr_valid &= ~NFS_ATTR_FATTR_CTIME;
3899 if (!(res.attr_bitmask[1] & FATTR4_WORD1_TIME_MODIFY))
3900 server->fattr_valid &= ~NFS_ATTR_FATTR_MTIME;
3901 #ifdef CONFIG_NFS_V4_SECURITY_LABEL
3902 if (!(res.attr_bitmask[2] & FATTR4_WORD2_SECURITY_LABEL))
3903 server->fattr_valid &= ~NFS_ATTR_FATTR_V4_SECURITY_LABEL;
3904 #endif
3905 memcpy(server->attr_bitmask_nl, res.attr_bitmask,
3906 sizeof(server->attr_bitmask));
3907 server->attr_bitmask_nl[2] &= ~FATTR4_WORD2_SECURITY_LABEL;
regards,
dan carpenter
reply other threads:[~2021-04-21 8:54 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=YH/oJpIhnG9aC5Cs@mwanda \
--to=dan.carpenter@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@primarydata.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).