]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
SUNRPC: Revert 241b1f419f0e ("SUNRPC: Remove xdr_buf_trim()")
authorChuck Lever <chuck.lever@oracle.com>
Wed, 15 Apr 2020 21:36:22 +0000 (17:36 -0400)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 20 May 2020 06:22:36 +0000 (08:22 +0200)
commit2151e1f2c1ea73a97b50dd115c2cbdd3f132714b
tree7e5cccfd17ad46fda31d2cbc9829f3c866b1091c
parent6b9c587512691388ac0e4ddf6d01fe158f508a14
SUNRPC: Revert 241b1f419f0e ("SUNRPC: Remove xdr_buf_trim()")

commit 0a8e7b7d08466b5fc52f8e96070acc116d82a8bb upstream.

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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
include/linux/sunrpc/xdr.h
net/sunrpc/auth_gss/gss_krb5_wrap.c
net/sunrpc/auth_gss/svcauth_gss.c
net/sunrpc/xdr.c