From: Hiroyuki Sato <hiroysato@gmail.com>
To: nfs <linux-nfs@vger.kernel.org>
Subject: Re: [Q] NFSD: COMPOUND reply tag padding not zeroed? (e.g. \xff\xff)
Date: Mon, 6 Apr 2026 13:22:17 +0900 [thread overview]
Message-ID: <CA+Tq-RouZ784rWHjwSz6GoJc4f5f66A2mr2-PdyFJ2bK2Y20wA@mail.gmail.com> (raw)
In-Reply-To: <CA+Tq-RqDP_BAroLX6wVrNY1BMwC9BOZ-UorLje=TXBdEOj8hjQ@mail.gmail.com>
Helo,
I can reproduce the same behavior on Linux 7.0-rc7 as well.
(591cd656a1bf5ea94a222af5ef2ee76df029c1d2)
The COMPOUND reply tag padding sometimes contains non-zero bytes
(e.g. 0x69, 0xff) instead of zero, which appears to be the same
issue as previously reported.
Would a change like the following make sense here?
It seems to zero-fill the XDR padding explicitly for the reply tag.
With this change applied, the padding appears to be zeroed
consistently in my testing.
Best regards,
diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
index 9d2349131..b33e031bf 100644
--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -6377,16 +6377,18 @@ nfs4svc_encode_compoundres(struct svc_rqst
*rqstp, struct xdr_stream *xdr)
{
struct nfsd4_compoundres *resp = rqstp->rq_resp;
__be32 *p;
+ size_t padded_len;
/*
* Send buffer space for the following items is reserved
* at the top of nfsd4_proc_compound().
*/
p = resp->statusp;
+ padded_len = XDR_QUADLEN(resp->taglen) * XDR_UNIT;
*p++ = resp->cstate.status;
*p++ = htonl(resp->taglen);
- memcpy(p, resp->tag, resp->taglen);
+ memcpy_and_pad(p, padded_len, resp->tag, resp->taglen, 0);
p += XDR_QUADLEN(resp->taglen);
*p++ = htonl(resp->opcnt);
2026年4月5日(日) 13:17 Hiroyuki Sato <hiroysato@gmail.com>:
>
> Hello,
>
> 1. Observed behavior
>
> * When sending a COMPOUND request with the tag "create_session" (14 bytes),
> the reply is expected to include XDR padding to a 4-byte boundary,
> i.e. "create_session" + "\x00\x00".
> * On 5.14.0-611.45.1.el9_7.x86_64 (AlmaLinux 9), the padding bytes
> are sometimes observed to be non-zero (e.g. "\xff\xff").
> * From inspection of recent upstream code, nfs4svc_encode_compoundres()
> also appears not to explicitly zero-fill the padding.
>
> 2. Questions
>
> * Is this understanding correct?
> * If so, is this a known issue or something that should be fixed?
>
> 3. Analysis
>
> * In nfsd4_proc_compound(), space for taglen + tag + opcnt is reserved via:
> xdr_reserve_space(resp->xdr, XDR_UNIT * 2 + args->taglen);
> * In nfs4svc_encode_compoundres(), only the tag payload is copied:
> memcpy(p, resp->tag, resp->taglen);
> * The pointer is then advanced using: p += XDR_QUADLEN(resp->taglen);
> * but the padding bytes do not appear to be explicitly zeroed.
> * As a result, it seems possible that uninitialized data remains in
> the padding region, which may explain why non-zero values
> such as \xff\xff appear on the wire.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/nfsd/nfs4proc.c#n3055
>
>
> ```C
> /*
> * COMPOUND call.
> */
> static __be32
> nfsd4_proc_compound(struct svc_rqst *rqstp)
> {
> // snip
> /* reserve space for: taglen, tag, and opcnt */
> xdr_reserve_space(resp->xdr, XDR_UNIT * 2 + args->taglen);
> ```
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/nfsd/nfs4xdr.c#n6389
>
>
> ```C
> bool
> nfs4svc_encode_compoundres(struct svc_rqst *rqstp, struct xdr_stream *xdr)
> {
> // snip
> memcpy(p, resp->tag, resp->taglen);
> p += XDR_QUADLEN(resp->taglen);
> ```
>
> 4. Additional observations
>
> * A packet capture excerpt (attached separately via gist) shows:
> (https://gist.github.com/hiroyuki-sato/8ab30dffbbd2499e8b4741d89fd383be)
> * The issue is not deterministic: when repeatedly sending CREATE_SESSION,
> it was observed roughly once every ~5 attempts.
> * This was discovered while implementing an NFSv4 client in Rust.
>
> Best regards,
>
> --
> Hiroyuki Sato
--
Hiroyuki Sato
next prev parent reply other threads:[~2026-04-06 4:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-05 4:17 [Q] NFSD: COMPOUND reply tag padding not zeroed? (e.g. \xff\xff) Hiroyuki Sato
2026-04-06 4:22 ` Hiroyuki Sato [this message]
2026-04-06 13:15 ` Chuck Lever
2026-04-07 5:23 ` Hiroyuki Sato
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=CA+Tq-RouZ784rWHjwSz6GoJc4f5f66A2mr2-PdyFJ2bK2Y20wA@mail.gmail.com \
--to=hiroysato@gmail.com \
--cc=linux-nfs@vger.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).