summaryrefslogtreecommitdiffstats
path: root/mm
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2018-11-01 14:39:53 +0100
committerDavid S. Miller <davem@davemloft.net>2018-11-03 07:59:26 +0100
commitc7e86acfcee30794dc99a0759924bf7b9d43f1ca (patch)
treec31ab320a0a156e97a0442c30e8859071a11d178 /mm
parentnet: dsa: microchip: initialize mutex before use (diff)
downloadlinux-c7e86acfcee30794dc99a0759924bf7b9d43f1ca.tar.xz
linux-c7e86acfcee30794dc99a0759924bf7b9d43f1ca.zip
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>
Diffstat (limited to 'mm')
0 files changed, 0 insertions, 0 deletions