aboutsummaryrefslogtreecommitdiff
path: root/net/ipv4/tcp_timer.c
diff options
context:
space:
mode:
authorAananth V <aananthv@google.com>2023-09-14 14:36:20 +0000
committerDavid S. Miller <davem@davemloft.net>2023-09-16 13:42:34 +0100
commite326578a21414738de45f77badd332fb00bd0f58 (patch)
tree0432d38ae1907442f930e6a3b84d257f43e3d23e /net/ipv4/tcp_timer.c
parent50675d84e3995f2606306b5e23e6847273a730e9 (diff)
downloadlinux-e326578a21414738de45f77badd332fb00bd0f58.tar.gz
linux-e326578a21414738de45f77badd332fb00bd0f58.tar.bz2
linux-e326578a21414738de45f77badd332fb00bd0f58.zip
tcp: call tcp_try_undo_recovery when an RTOd TFO SYNACK is ACKed
For passive TCP Fast Open sockets that had SYN/ACK timeout and did not send more data in SYN_RECV, upon receiving the final ACK in 3WHS, the congestion state may awkwardly stay in CA_Loss mode unless the CA state was undone due to TCP timestamp checks. However, if tcp_rcv_synrecv_state_fastopen() decides not to undo, then we should enter CA_Open, because at that point we have received an ACK covering the retransmitted SYNACKs. Currently, the icsk_ca_state is only set to CA_Open after we receive an ACK for a data-packet. This is because tcp_ack does not call tcp_fastretrans_alert (and tcp_process_loss) if !prior_packets Note that tcp_process_loss() calls tcp_try_undo_recovery(), so having tcp_rcv_synrecv_state_fastopen() decide that if we're in CA_Loss we should call tcp_try_undo_recovery() is consistent with that, and low risk. Fixes: dad8cea7add9 ("tcp: fix TFO SYNACK undo to avoid double-timestamp-undo") Signed-off-by: Aananth V <aananthv@google.com> Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: Yuchung Cheng <ycheng@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/ipv4/tcp_timer.c')
0 files changed, 0 insertions, 0 deletions