From: Mike Snitzer <snitzer@kernel.org>
To: Trond Myklebust <trondmy@kernel.org>, Anna Schumaker <anna@kernel.org>
Cc: Tom Haynes <loghyr@hammerspace.com>, Chuck Lever <cel@kernel.org>,
linux-nfs@vger.kernel.org
Subject: [PATCH v2 5/6] nfs4.2: request UNCACHEABLE_DIRENT_METADATA only for directories
Date: Tue, 30 Jun 2026 19:42:56 -0400 [thread overview]
Message-ID: <20260630234257.5615-6-snitzer@kernel.org> (raw)
In-Reply-To: <20260630234257.5615-1-snitzer@kernel.org>
The UNCACHEABLE_DIRENT_METADATA attribute (attr 88) applies only to
directory objects (NF4DIR); per draft-ietf-nfsv4-uncacheable-directories
a server must reject a query of it on any other object type with
NFS4ERR_INVAL. Gate the request by object type at the single choke point
nfs4_bitmap_copy_adjust(), stripping FATTR4_WORD2_UNCACHEABLE_DIRENT_METADATA
unless the target is known to be a directory (callers with an unknown
object type, e.g. LOOKUP/LOOKUPP/CREATE, pass a NULL inode and are already
routed through this helper). This mirrors the NF4REG gating of the
companion UNCACHEABLE_FILE_DATA attribute: a regular file requests
file_data and never dirent_metadata, a directory requests dirent_metadata
and never file_data, and an unknown/other object requests neither.
The bit stays in server->attr_bitmask, so OPEN (which requests the
regular-file open bitmap) is unaffected. This type gate runs before the
helper's read/write (file) delegation handling and is the only adjustment
the directory attribute needs: a directory cannot hold a file delegation,
so the delegation-based suppression below it never applies.
See: https://datatracker.ietf.org/doc/draft-ietf-nfsv4-uncacheable-directories/
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Assisted-by: Claude:claude-opus-4-8
---
fs/nfs/nfs4proc.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index d912f6a43978..a4c40e12d621 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -312,13 +312,16 @@ static void nfs4_bitmap_copy_adjust(__u32 *dst, const __u32 *src,
memcpy(dst, src, NFS4_BITMASK_SZ*sizeof(*dst));
/*
* The uncacheable_file_data attribute applies only to regular files
- * (NF4REG); a server must reject a query of it on any other object
- * type with NFS4ERR_INVAL. Never request it unless the target is
- * known to be a regular file (callers with an unknown object type,
- * e.g. LOOKUP, pass a NULL inode).
+ * (NF4REG) and the uncacheable_dirent_metadata attribute only to
+ * directories (NF4DIR); a server must reject a query of either on any
+ * other object type with NFS4ERR_INVAL. Never request either unless
+ * the target is known to be of the matching type (callers with an
+ * unknown object type, e.g. LOOKUP, pass a NULL inode).
*/
if (!inode || !S_ISREG(inode->i_mode))
dst[2] &= ~FATTR4_WORD2_UNCACHEABLE_FILE_DATA;
+ if (!inode || !S_ISDIR(inode->i_mode))
+ dst[2] &= ~FATTR4_WORD2_UNCACHEABLE_DIRENT_METADATA;
if (!inode || !nfs_have_read_or_write_delegation(inode))
return;
--
2.47.3
next prev parent reply other threads:[~2026-06-30 23:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 23:42 [PATCH v2 0/6] nfs: NFSv4.2 client support for UNCACHEABLE_FILE_DATA and UNCACHEABLE_DIRENT_METADATA Mike Snitzer
2026-06-30 23:42 ` [PATCH v2 1/6] nfs4.2: add UNCACHEABLE_FILE_DATA attribute support Mike Snitzer
2026-06-30 23:42 ` [PATCH v2 2/6] nfs4.2: request UNCACHEABLE_FILE_DATA only for regular files Mike Snitzer
2026-06-30 23:42 ` [PATCH v2 3/6] nfs4.2: open UNCACHEABLE_FILE_DATA files with O_DIRECT Mike Snitzer
2026-06-30 23:42 ` [PATCH v2 4/6] nfs4.2: add UNCACHEABLE_DIRENT_METADATA attribute support Mike Snitzer
2026-06-30 23:42 ` Mike Snitzer [this message]
2026-06-30 23:42 ` [PATCH v2 6/6] nfs4.2: honor UNCACHEABLE_DIRENT_METADATA by refetching readdir Mike Snitzer
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=20260630234257.5615-6-snitzer@kernel.org \
--to=snitzer@kernel.org \
--cc=anna@kernel.org \
--cc=cel@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=loghyr@hammerspace.com \
--cc=trondmy@kernel.org \
/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