nfs4.2: request UNCACHEABLE_FILE_DATA only for regular files

The UNCACHEABLE_FILE_DATA attribute applies only to regular files
(NF4REG); per draft-ietf-nfsv4-uncacheable-files a server MUST reject a
query of it on any other object type with NFS4ERR_INVAL.  The previous
commit decodes and tracks the attribute but does not gate it: the bit
rides in the per-server attribute bitmask (server->attr_bitmask) and in
the generic getattr request bitmap (nfs4_fattr_bitmap), so it would be
requested for non-regular objects too -- e.g. a plain directory GETATTR,
a LOOKUP that resolves to a directory, or a CREATE (which only ever makes
non-regular objects).  A strict server would fail those compounds.

Gate the client accordingly:

 - Only set NFS_INO_INVALID_UNCACHEABLE_FILE_DATA on regular-file inodes.
   In particular, drop it from nfs4_update_changeattr_locked()'s
   force-revalidation aggregation: that helper only ever runs on
   directory inodes (its callers update a directory's change information
   after OPEN-create, REMOVE, RENAME and LINK), so it was setting the
   file-only bit on directories.

 - Gate the request by object type at the choke point
   nfs4_bitmap_copy_adjust(), which clears
   FATTR4_WORD2_UNCACHEABLE_FILE_DATA unless the target inode is a
   regular file (a NULL inode -- unknown object type -- clears it too).
   This already covers GETATTR, SETATTR and LINK; route LOOKUP, LOOKUPP
   and CREATE through it as well.

 - Type-gate nfs4_bitmask_set(), which translates
   NFS_INO_INVALID_UNCACHEABLE_FILE_DATA into a request for attr 87 in
   the getattr attached to WRITE, CLOSE and DELEGRETURN.  WRITE and
   CLOSE only ever pass regular files, but DELEGRETURN passes whatever
   object held the delegation -- with directory delegation support that
   includes directories -- so request attr 87 there only for S_ISREG
   inodes.

The bit is kept in server->attr_bitmask (it is server-supported, and OPEN
still requests it via its regular-file-only open_bitmap), so no bespoke
per-data-file bitmask plumbing is needed.  The remaining getattr-bearing
compounds are already safe: ACCESS and LAYOUTCOMMIT use
server->cache_consistency_bitmask (no word2 attributes); READDIR does not
encode the bit; and LOOKUP_ROOT, FSINFO, STATFS and PATHCONF use fixed
bitmaps without it.

Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>

0 files changed, 0 insertions, 0 deletions