diff options
| author | Paolo Abeni <[email protected]> | 2025-07-21 17:20:21 +0000 |
|---|---|---|
| committer | Jakub Kicinski <[email protected]> | 2025-07-23 01:21:15 +0000 |
| commit | 972ca7a3bc9a136b15ba698713b056a4900e2634 (patch) | |
| tree | 8ab2297a25df1d55c95e5d4a937605d8744cb164 /drivers/platform/x86/intel/atomisp2/pm.c | |
| parent | Merge branch 'net-mlx5-misc-changes-2025-07-21' (diff) | |
| download | kernel-972ca7a3bc9a136b15ba698713b056a4900e2634.tar.gz kernel-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 <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Eric Dumazet <[email protected]>
Link: https://patch.msgid.link/20c18165d3f848e1c5c1b782d88c1a5ab38b3f70.1753118029.git.pabeni@redhat.com
Signed-off-by: Jakub Kicinski <[email protected]>
Diffstat (limited to 'drivers/platform/x86/intel/atomisp2/pm.c')
0 files changed, 0 insertions, 0 deletions
