rxrpc: Don't try to resend the request if we're receiving the reply
authorDavid Howells <dhowells@redhat.com>
Sat, 21 May 2022 08:03:11 +0000 (09:03 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 9 Jun 2022 08:23:02 +0000 (10:23 +0200)
commitcea2196643b2a67ebd3ea496dade2f32eb2081a7
treef3a71d1c1d665da9a235ae70964a13c232a58662
parentb3a9b227d5e7467b8518160ff034ea22bb9de573
rxrpc: Don't try to resend the request if we're receiving the reply

[ Upstream commit 114af61f88fbe34d641b13922d098ffec4c1be1b ]

rxrpc has a timer to trigger resending of unacked data packets in a call.
This is not cancelled when a client call switches to the receive phase on
the basis that most calls don't last long enough for it to ever expire.
However, if it *does* expire after we've started to receive the reply, we
shouldn't then go into trying to retransmit or pinging the server to find
out if an ack got lost.

Fix this by skipping the resend code if we're into receiving the reply to a
client call.

Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-afs@lists.infradead.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
net/rxrpc/call_event.c