diff options
author | Aananth V <aananthv@google.com> | 2023-09-14 14:36:20 +0000 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2023-09-16 13:42:34 +0100 |
commit | e326578a21414738de45f77badd332fb00bd0f58 (patch) | |
tree | 0432d38ae1907442f930e6a3b84d257f43e3d23e /net/ipv4/tcp_timer.c | |
parent | 50675d84e3995f2606306b5e23e6847273a730e9 (diff) | |
download | linux-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