From: Nikhil Jha via B4 Relay <devnull+njha.janestreet.com@kernel.org>
To: Trond Myklebust <trondmy@kernel.org>,
Anna Schumaker <anna@kernel.org>,
Chuck Lever <chuck.lever@oracle.com>,
Jeff Layton <jlayton@kernel.org>, Neil Brown <neilb@suse.de>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
Nikhil Jha <njha@janestreet.com>
Subject: [PATCH v2 0/2] fix gss seqno handling to be more rfc-compliant
Date: Wed, 19 Mar 2025 13:02:38 -0400 [thread overview]
Message-ID: <20250319-rfc2203-seqnum-cache-v2-0-2c98b859f2dd@janestreet.com> (raw)
When the client retransmits an operation (for example, because the
server is slow to respond), a new GSS sequence number is associated with
the XID. In the current kernel code the original sequence number is
discarded. Subsequently, if a response to the original request is
received there will be a GSS sequence number mismatch. A mismatch will
trigger another retransmit, possibly repeating the cycle, and after some
number of failed retries EACCES is returned.
RFC2203, section 5.3.3.1 suggests a possible solution... “cache the
RPCSEC_GSS sequence number of each request it sends” and "compute the
checksum of each sequence number in the cache to try to match the
checksum in the reply's verifier." This is what FreeBSD’s implementation
does (rpc_gss_validate in sys/rpc/rpcsec_gss/rpcsec_gss.c).
However, even with this cache, retransmits directly caused by a seqno
mismatch can still cause a bad message interleaving that results in this
bug. The RFC already suggests ignoring incorrect seqnos on the server
side, and this seems symmetric, so this patchset also applies that
behavior to the client.
These two patches are *not* dependent on each other. I tested them by
delaying packets with a Python script hooked up to NFQUEUE. If it would
be helpful I can send this script along as well.
Signed-off-by: Nikhil Jha <njha@janestreet.com>
---
Changes since v1:
* Maintain the invariant that the first seqno is always first in
rq_seqnos, so that it doesn't need to be stored twice.
* Minor formatting, and resending with proper mailing-list headers so the
patches are easier to work with.
---
Nikhil Jha (2):
sunrpc: implement rfc2203 rpcsec_gss seqnum cache
sunrpc: don't immediately retransmit on seqno miss
include/linux/sunrpc/xprt.h | 17 +++++++++++-
include/trace/events/rpcgss.h | 4 +--
include/trace/events/sunrpc.h | 2 +-
net/sunrpc/auth_gss/auth_gss.c | 59 ++++++++++++++++++++++++++----------------
net/sunrpc/clnt.c | 9 +++++--
net/sunrpc/xprt.c | 3 ++-
6 files changed, 64 insertions(+), 30 deletions(-)
---
base-commit: 7eb172143d5508b4da468ed59ee857c6e5e01da6
change-id: 20250314-rfc2203-seqnum-cache-52389d14f567
Best regards,
--
Nikhil Jha <njha@janestreet.com>
next reply other threads:[~2025-03-19 17:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-19 17:02 Nikhil Jha via B4 Relay [this message]
2025-03-19 17:02 ` [PATCH v2 1/2] sunrpc: implement rfc2203 rpcsec_gss seqnum cache Nikhil Jha via B4 Relay
2025-03-19 17:02 ` [PATCH v2 2/2] sunrpc: don't immediately retransmit on seqno miss Nikhil Jha via B4 Relay
2025-03-20 13:16 ` [PATCH v2 0/2] fix gss seqno handling to be more rfc-compliant Chuck Lever
2025-06-11 18:50 ` Nikhil Jha
2025-06-11 18:54 ` Chuck Lever
2025-06-11 19:05 ` Nikhil Jha
2025-06-11 19:10 ` Chuck Lever
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=20250319-rfc2203-seqnum-cache-v2-0-2c98b859f2dd@janestreet.com \
--to=devnull+njha.janestreet.com@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=anna@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jlayton@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=neilb@suse.de \
--cc=netdev@vger.kernel.org \
--cc=njha@janestreet.com \
--cc=okorniev@redhat.com \
--cc=pabeni@redhat.com \
--cc=rostedt@goodmis.org \
--cc=tom@talpey.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