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: 1d2fbaad7c ("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>
This commit is contained in:
Paolo Abeni 2025-07-21 19:20:21 +02:00 committed by Jakub Kicinski
parent 8839d1cc6c
commit 972ca7a3bc

View File

@ -5549,6 +5549,10 @@ static int tcp_prune_queue(struct sock *sk, const struct sk_buff *in_skb)
{
struct tcp_sock *tp = tcp_sk(sk);
/* Do nothing if our queues are empty. */
if (!atomic_read(&sk->sk_rmem_alloc))
return -1;
NET_INC_STATS(sock_net(sk), LINUX_MIB_PRUNECALLED);
if (!tcp_can_ingest(sk, in_skb))