https://github.com/torvalds/linux
Revision 686dc2db2a0fdc1d34b424ec2c0a735becd8d62b authored by Neal Cardwell on 03 September 2022, 12:10:23 UTC, committed by Paolo Abeni on 06 September 2022, 09:06:31 UTC
Fix a bug reported and analyzed by Nagaraj Arankal, where the handling of a spurious non-SACK RTO could cause a connection to fail to clear retrans_stamp, causing a later RTO to very prematurely time out the connection with ETIMEDOUT. Here is the buggy scenario, expanding upon Nagaraj Arankal's excellent report: (*1) Send one data packet on a non-SACK connection (*2) Because no ACK packet is received, the packet is retransmitted and we enter CA_Loss; but this retransmission is spurious. (*3) The ACK for the original data is received. The transmitted packet is acknowledged. The TCP timestamp is before the retrans_stamp, so tcp_may_undo() returns true, and tcp_try_undo_loss() returns true without changing state to Open (because tcp_is_sack() is false), and tcp_process_loss() returns without calling tcp_try_undo_recovery(). Normally after undoing a CA_Loss episode, tcp_fastretrans_alert() would see that the connection has returned to CA_Open and fall through and call tcp_try_to_open(), which would set retrans_stamp to 0. However, for non-SACK connections we hold the connection in CA_Loss, so do not fall through to call tcp_try_to_open() and do not set retrans_stamp to 0. So retrans_stamp is (erroneously) still non-zero. At this point the first "retransmission event" has passed and been recovered from. Any future retransmission is a completely new "event". However, retrans_stamp is erroneously still set. (And we are still in CA_Loss, which is correct.) (*4) After 16 minutes (to correspond with tcp_retries2=15), a new data packet is sent. Note: No data is transmitted between (*3) and (*4) and we disabled keep alives. The socket's timeout SHOULD be calculated from this point in time, but instead it's calculated from the prior "event" 16 minutes ago (step (*2)). (*5) Because no ACK packet is received, the packet is retransmitted. (*6) At the time of the 2nd retransmission, the socket returns ETIMEDOUT, prematurely, because retrans_stamp is (erroneously) too far in the past (set at the time of (*2)). This commit fixes this bug by ensuring that we reuse in tcp_try_undo_loss() the same careful logic for non-SACK connections that we have in tcp_try_undo_recovery(). To avoid duplicating logic, we factor out that logic into a new tcp_is_non_sack_preventing_reopen() helper and call that helper from both undo functions. Fixes: da34ac7626b5 ("tcp: only undo on partial ACKs in CA_Loss") Reported-by: Nagaraj Arankal <nagaraj.p.arankal@hpe.com> Link: https://lore.kernel.org/all/SJ0PR84MB1847BE6C24D274C46A1B9B0EB27A9@SJ0PR84MB1847.NAMPRD84.PROD.OUTLOOK.COM/ Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: Yuchung Cheng <ycheng@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20220903121023.866900-1-ncardwell.kernel@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
1 parent beb4325
Tip revision: 686dc2db2a0fdc1d34b424ec2c0a735becd8d62b authored by Neal Cardwell on 03 September 2022, 12:10:23 UTC
tcp: fix early ETIMEDOUT after spurious non-SACK RTO
tcp: fix early ETIMEDOUT after spurious non-SACK RTO
Tip revision: 686dc2d
File | Mode | Size |
---|---|---|
Documentation | ||
LICENSES | ||
arch | ||
block | ||
certs | ||
crypto | ||
drivers | ||
fs | ||
include | ||
init | ||
io_uring | ||
ipc | ||
kernel | ||
lib | ||
mm | ||
net | ||
samples | ||
scripts | ||
security | ||
sound | ||
tools | ||
usr | ||
virt | ||
.clang-format | -rw-r--r-- | 19.9 KB |
.cocciconfig | -rw-r--r-- | 59 bytes |
.get_maintainer.ignore | -rw-r--r-- | 151 bytes |
.gitattributes | -rw-r--r-- | 62 bytes |
.gitignore | -rw-r--r-- | 1.9 KB |
.mailmap | -rw-r--r-- | 23.7 KB |
COPYING | -rw-r--r-- | 496 bytes |
CREDITS | -rw-r--r-- | 99.1 KB |
Kbuild | -rw-r--r-- | 1.3 KB |
Kconfig | -rw-r--r-- | 555 bytes |
MAINTAINERS | -rw-r--r-- | 663.6 KB |
Makefile | -rw-r--r-- | 64.5 KB |
README | -rw-r--r-- | 727 bytes |
Computing file changes ...