From: Hiroyuki Sato <hiroysato@gmail.com>
To: Chuck Lever <cel@kernel.org>
Cc: nfs <linux-nfs@vger.kernel.org>
Subject: Re: [Q] NFSD: COMPOUND reply tag padding not zeroed? (e.g. \xff\xff)
Date: Tue, 7 Apr 2026 14:23:18 +0900 [thread overview]
Message-ID: <CA+Tq-RqYx4iuWuF0LpSKuxwhM3agxwvDUG9-r0Ob-Z_NLoJJwQ@mail.gmail.com> (raw)
In-Reply-To: <d259c550-4cf3-425d-8485-86c126c1d256@app.fastmail.com>
Hello, Thank you for your comment.
I'm new to Linux kernel development, but I'll prepare a patch and send it later.
Best regards,
2026年4月6日(月) 22:15 Chuck Lever <cel@kernel.org>:
>
>
>
> 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
--
Hiroyuki Sato
prev parent reply other threads:[~2026-04-07 5:23 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
2026-04-07 5:23 ` Hiroyuki Sato [this message]
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-RqYx4iuWuF0LpSKuxwhM3agxwvDUG9-r0Ob-Z_NLoJJwQ@mail.gmail.com \
--to=hiroysato@gmail.com \
--cc=cel@kernel.org \
--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).