summaryrefslogtreecommitdiff
path: root/security
diff options
context:
space:
mode:
authorChuck Lever <chuck.lever@oracle.com>2020-04-15 17:36:22 -0400
committerChuck Lever <chuck.lever@oracle.com>2020-04-27 10:58:30 -0400
commit0a8e7b7d08466b5fc52f8e96070acc116d82a8bb (patch)
tree5d970e9546b444a329fc41b466ceb0d31ebf4240 /security
parenta7e429a6fa6d612d1dacde96c885dc1bb4a9f400 (diff)
SUNRPC: Revert 241b1f419f0e ("SUNRPC: Remove xdr_buf_trim()")
I've noticed that when krb5i or krb5p security is in use, retransmitted requests are missing the server's duplicate reply cache. The computed checksum on the retransmitted request does not match the cached checksum, resulting in the server performing the retransmitted request again instead of returning the cached reply. The assumptions made when removing xdr_buf_trim() were not correct. In the send paths, the upper layer has already set the segment lengths correctly, and shorting the buffer's content is simply a matter of reducing buf->len. xdr_buf_trim() is the right answer in the receive/unwrap path on both the client and the server. The buffer segment lengths have to be shortened one-by-one. On the server side in particular, head.iov_len needs to be updated correctly to enable nfsd_cache_csum() to work correctly. The simple buf->len computation doesn't do that, and that results in checksumming stale data in the buffer. The problem isn't noticed until there's significant instability of the RPC transport. At that point, the reliability of retransmit detection on the server becomes crucial. Fixes: 241b1f419f0e ("SUNRPC: Remove xdr_buf_trim()") Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Diffstat (limited to 'security')
0 files changed, 0 insertions, 0 deletions