summaryrefslogtreecommitdiffstats
path: root/lib
diff options
context:
space:
mode:
authorJason Xing <kernelxing@tencent.com>2023-08-11 10:37:47 +0800
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2023-08-23 17:32:56 +0200
commitb237550e1f1bd1bd5f5e76af7a426e79c83fe71a (patch)
treecb538c1c57b1fb4dd77397339f85f2640a822eab /lib
parent4a3fcfc3b51796e5e6974041c9a7cf7808d16f9e (diff)
downloadlinux-stable-b237550e1f1bd1bd5f5e76af7a426e79c83fe71a.tar.gz
linux-stable-b237550e1f1bd1bd5f5e76af7a426e79c83fe71a.tar.bz2
linux-stable-b237550e1f1bd1bd5f5e76af7a426e79c83fe71a.zip
net: fix the RTO timer retransmitting skb every 1ms if linear option is enabled
commit e4dd0d3a2f64b8bd8029ec70f52bdbebd0644408 upstream. In the real workload, I encountered an issue which could cause the RTO timer to retransmit the skb per 1ms with linear option enabled. The amount of lost-retransmitted skbs can go up to 1000+ instantly. The root cause is that if the icsk_rto happens to be zero in the 6th round (which is the TCP_THIN_LINEAR_RETRIES value), then it will always be zero due to the changed calculation method in tcp_retransmit_timer() as follows: icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX); Above line could be converted to icsk->icsk_rto = min(0 << 1, TCP_RTO_MAX) = 0 Therefore, the timer expires so quickly without any doubt. I read through the RFC 6298 and found that the RTO value can be rounded up to a certain value, in Linux, say TCP_RTO_MIN as default, which is regarded as the lower bound in this patch as suggested by Eric. Fixes: 36e31b0af587 ("net: TCP thin linear timeouts") Suggested-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Jason Xing <kernelxing@tencent.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions