From: Mike Snitzer <snitzer@hammerspace.com>
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 v3 5/6] nfs4.2: request UNCACHEABLE_DIRENT_METADATA only for directories
Date: Wed, 1 Jul 2026 16:43:36 -0400 [thread overview]
Message-ID: <20260701204337.54314-6-snitzer@kernel.org> (raw)
In-Reply-To: <20260701204337.54314-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 4c8436ac5cfc..273fc9fc5fd7 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-07-01 20:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 20:43 [PATCH v3 0/6] nfs: NFSv4.2 client support for UNCACHEABLE_FILE_DATA and UNCACHEABLE_DIRENT_METADATA Mike Snitzer
2026-07-01 20:43 ` [PATCH v3 1/6] nfs4.2: add UNCACHEABLE_FILE_DATA attribute support Mike Snitzer
2026-07-01 20:43 ` [PATCH v3 2/6] nfs4.2: request UNCACHEABLE_FILE_DATA only for regular files Mike Snitzer
2026-07-01 20:43 ` [PATCH v3 3/6] nfs4.2: open UNCACHEABLE_FILE_DATA files with O_DIRECT Mike Snitzer
2026-07-01 20:43 ` [PATCH v3 4/6] nfs4.2: add UNCACHEABLE_DIRENT_METADATA attribute support Mike Snitzer
2026-07-01 20:43 ` Mike Snitzer [this message]
2026-07-01 20:43 ` [PATCH v3 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=20260701204337.54314-6-snitzer@kernel.org \
--to=snitzer@hammerspace.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.