rxrpc: Fix lockup due to no error backoff after ack transmit error
authorDavid Howells <dhowells@redhat.com>
Thu, 1 Nov 2018 13:39:53 +0000 (13:39 +0000)
committerDavid S. Miller <davem@davemloft.net>
Sat, 3 Nov 2018 06:59:26 +0000 (23:59 -0700)
commitc7e86acfcee30794dc99a0759924bf7b9d43f1ca
treec31ab320a0a156e97a0442c30e8859071a11d178
parent284fb78ed7572117846f8e1d1d8e3dbfd16880c2
rxrpc: Fix lockup due to no error backoff after ack transmit error

If the network becomes (partially) unavailable, say by disabling IPv6, the
background ACK transmission routine can get itself into a tizzy by
proposing immediate ACK retransmission.  Since we're in the call event
processor, that happens immediately without returning to the workqueue
manager.

The condition should clear after a while when either the network comes back
or the call times out.

Fix this by:

 (1) When re-proposing an ACK on failed Tx, don't schedule it immediately.
     This will allow a certain amount of time to elapse before we try
     again.

 (2) Enforce a return to the workqueue manager after a certain number of
     iterations of the call processing loop.

 (3) Add a backoff delay that increases the delay on deferred ACKs by a
     jiffy per failed transmission to a limit of HZ.  The backoff delay is
     cleared on a successful return from kernel_sendmsg().

 (4) Cancel calls immediately if the opening sendmsg fails.  The layer
     above can arrange retransmission or rotate to another server.

Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code")
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/rxrpc/ar-internal.h
net/rxrpc/call_event.c
net/rxrpc/output.c