aboutsummaryrefslogtreecommitdiff
path: root/sys/contrib/openzfs/tests/zfs-tests/tests/functional/cli_root/zfs_upgrade/zfs_upgrade_004_pos.ksh
diff options
context:
space:
mode:
authorGleb Smirnoff <glebius@FreeBSD.org>2022-08-10 14:32:37 +0000
committerGleb Smirnoff <glebius@FreeBSD.org>2022-08-10 14:32:37 +0000
commitd88eb4654f372d0451139a1dbf525a8f2cad1cf8 (patch)
tree0152c40daa1f6208e89852fce5049e60a2e0b818 /sys/contrib/openzfs/tests/zfs-tests/tests/functional/cli_root/zfs_upgrade/zfs_upgrade_004_pos.ksh
parentf998535a66b986f51dd65b5153d1a580d50ddfbe (diff)
downloadsrc-d88eb4654f372d0451139a1dbf525a8f2cad1cf8.tar.gz
src-d88eb4654f372d0451139a1dbf525a8f2cad1cf8.zip
tcp: address a wire level race with 2 ACKs at the end of TCP handshake
Imagine we are in SYN-RCVD state and two ACKs arrive at the same time, both valid, e.g. coming from the same host and with valid sequence. First packet would locate the listening socket in the inpcb database, write-lock it and start expanding the syncache entry into a socket. Meanwhile second packet would wait on the write lock of the listening socket. First packet will create a new ESTABLISHED socket, free the syncache entry and unlock the listening socket. Second packet would call into syncache_expand(), but this time it will fail as there is no syncache entry. Second packet would generate RST, effectively resetting the remote connection. It seems to me, that it is impossible to solve this problem with just rearranging locks, as the race happens at a wire level. To solve the problem, for an ACK packet arrived on a listening socket, that failed syncache lookup, perform a second non-wildcard lookup right away. That lookup may find the new born socket. Otherwise, we indeed send RST. Tested by: kp Reviewed by: tuexen, rrs PR: 265154 Differential revision: https://reviews.freebsd.org/D36066
Diffstat (limited to 'sys/contrib/openzfs/tests/zfs-tests/tests/functional/cli_root/zfs_upgrade/zfs_upgrade_004_pos.ksh')
0 files changed, 0 insertions, 0 deletions