diff options
author | 2025-07-21 19:20:21 +0200 | |
---|---|---|
committer | 2025-07-22 18:21:15 -0700 | |
commit | 972ca7a3bc9a136b15ba698713b056a4900e2634 (patch) | |
tree | 8ab2297a25df1d55c95e5d4a937605d8744cb164 /tools/perf/scripts/python | |
parent | Merge branch 'net-mlx5-misc-changes-2025-07-21' (diff) | |
download | wireguard-linux-972ca7a3bc9a136b15ba698713b056a4900e2634.tar.xz wireguard-linux-972ca7a3bc9a136b15ba698713b056a4900e2634.zip |
tcp: do not set a zero size receive buffer
The nipa CI is reporting frequent failures in the mptcp_connect
self-tests.
In the failing scenarios (TCP -> MPTCP) the involved sockets are
actually plain TCP ones, as fallback for passive socket at 2whs
time cause the MPTCP listener to actually create a TCP socket.
The transfer is stuck due to the receiver buffer being zero.
With the stronger check in place, tcp_clamp_window() can be invoked
while the TCP socket has sk_rmem_alloc == 0, and the receive buffer
will be zeroed, too.
Check for the critical condition in tcp_prune_queue() and just
drop the packet without shrinking the receiver buffer.
Fixes: 1d2fbaad7cd8 ("tcp: stronger sk_rcvbuf checks")
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20c18165d3f848e1c5c1b782d88c1a5ab38b3f70.1753118029.git.pabeni@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions