From: "Chuck Lever" <cel@kernel.org>
To: "Hiroyuki Sato" <hiroysato@gmail.com>, nfs <linux-nfs@vger.kernel.org>
Subject: Re: [Q] NFSD: COMPOUND reply tag padding not zeroed? (e.g. \xff\xff)
Date: Mon, 06 Apr 2026 09:15:19 -0400 [thread overview]
Message-ID: <d259c550-4cf3-425d-8485-86c126c1d256@app.fastmail.com> (raw)
In-Reply-To: <CA+Tq-RouZ784rWHjwSz6GoJc4f5f66A2mr2-PdyFJ2bK2Y20wA@mail.gmail.com>
On Mon, Apr 6, 2026, at 12:22 AM, Hiroyuki Sato wrote:
> 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?
I think the rules are:
1. The sender SHOULD clear the bytes in an XDR pad but doesn't have to
2. The receiver MUST ignore the bytes in an XDR pad
Feel free to clean up your fix and send it as a contribution with
a full patch description (Signed-off-by, Fixes tags, etc etc).
--
Chuck Lever
next prev parent reply other threads:[~2026-04-06 13:15 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
2026-04-06 13:15 ` Chuck Lever [this message]
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=d259c550-4cf3-425d-8485-86c126c1d256@app.fastmail.com \
--to=cel@kernel.org \
--cc=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).