summaryrefslogtreecommitdiff
path: root/net/packet
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2018-11-01 16:39:53 +0300
committerDavid S. Miller <davem@davemloft.net>2018-11-03 09:59:26 +0300
commitc7e86acfcee30794dc99a0759924bf7b9d43f1ca (patch)
treec31ab320a0a156e97a0442c30e8859071a11d178 /net/packet
parent284fb78ed7572117846f8e1d1d8e3dbfd16880c2 (diff)
downloadlinux-c7e86acfcee30794dc99a0759924bf7b9d43f1ca.tar.xz
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 'net/packet')
0 files changed, 0 insertions, 0 deletions