diff options
author | 2025-03-19 13:02:39 -0400 | |
---|---|---|
committer | 2025-05-19 10:14:29 -0400 | |
commit | 08d6ee6d8a10aef958c2af16bb121070290ed589 (patch) | |
tree | 8846bf8be74aa11b043ecb429ac851d97e8b2199 /scripts/lib/kdoc/kdoc_files.py | |
parent | Linux 6.15-rc7 (diff) | |
download | linux-rng-08d6ee6d8a10aef958c2af16bb121070290ed589.tar.xz linux-rng-08d6ee6d8a10aef958c2af16bb121070290ed589.zip |
sunrpc: implement rfc2203 rpcsec_gss seqnum cache
This implements a sequence number cache of the last three (right now
hardcoded) sent sequence numbers for a given XID, as suggested by the
RFC.
From RFC2203 5.3.3.1:
"Note that the sequence number algorithm requires that the client
increment the sequence number even if it is retrying a request with
the same RPC transaction identifier. It is not infrequent for
clients to get into a situation where they send two or more attempts
and a slow server sends the reply for the first attempt. With
RPCSEC_GSS, each request and reply will have a unique sequence
number. If the client wishes to improve turn around time on the RPC
call, it can cache the RPCSEC_GSS sequence number of each request it
sends. Then when it receives a response with a matching RPC
transaction identifier, it can compute the checksum of each sequence
number in the cache to try to match the checksum in the reply's
verifier."
Signed-off-by: Nikhil Jha <njha@janestreet.com>
Acked-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <anna.schumaker@oracle.com>
Diffstat (limited to 'scripts/lib/kdoc/kdoc_files.py')
0 files changed, 0 insertions, 0 deletions