public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Ankit Jain <ankit-aj.jain@broadcom.com>
To: edumazet@google.com, kuba@kernel.org, netdev@vger.kernel.org
Cc: davem@davemloft.net, pabeni@redhat.com, ncardwell@google.com,
	kuniyu@google.com, horms@kernel.org, shuah@kernel.org,
	quic_subashab@quicinc.com, quic_stranche@quicinc.com,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
	karen.badiryan@broadcom.com, ajay.kaher@broadcom.com,
	alexey.makhalov@broadcom.com,
	vamsi-krishna.brahmajosyula@broadcom.com, yin.ding@broadcom.com,
	tapas.kundu@broadcom.com, Ankit Jain <ankit-aj.jain@broadcom.com>
Subject: [PATCH net v2 2/2] selftests/net: add packetdrill test for locked SO_RCVBUF SWS
Date: Mon,  4 May 2026 14:49:45 +0000	[thread overview]
Message-ID: <20260504144945.13477-3-ankit-aj.jain@broadcom.com> (raw)
In-Reply-To: <20260504144945.13477-1-ankit-aj.jain@broadcom.com>

Add a packetdrill test to verify that TCP does not aggressively penalize
the `scaling_ratio` when an application explicitly locks the receive
buffer via SO_RCVBUF.

This test establishes a connection with a very small MSS, then injects
small payloads. On buggy kernels, the payload-to-truesize memory penalty
drops the `scaling_ratio` to 1, which shrinks the dynamically calculated
window and causes Silly Window Syndrome (SWS).

The test asserts that `tcpi_rcv_ssthresh` (the exposed window clamp)
remains protected and stays at a healthy level.

Signed-off-by: Ankit Jain <ankit-aj.jain@broadcom.com>
---
 .../net/packetdrill/tcp_locked_rcvbuf_sws.pkt | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 tools/testing/selftests/net/packetdrill/tcp_locked_rcvbuf_sws.pkt

diff --git a/tools/testing/selftests/net/packetdrill/tcp_locked_rcvbuf_sws.pkt b/tools/testing/selftests/net/packetdrill/tcp_locked_rcvbuf_sws.pkt
new file mode 100644
index 000000000000..96d3a0813548
--- /dev/null
+++ b/tools/testing/selftests/net/packetdrill/tcp_locked_rcvbuf_sws.pkt
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0
+// Test that TCP does not apply aggressive truesize penalties
+// to the scaling_ratio when the application has explicitly locked
+// the receive buffer, preventing Silly Window Syndrome.
+
+// 1. Create a socket and lock SO_RCVBUF to 32K
+0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
++0 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0
++0 bind(3, ..., ...) = 0
++0 listen(3, 1) = 0
+
+// 2. Establish connection with a TINY MSS (48 bytes)
+// This forces the kernel's rcv_mss expectation to initialize at rock bottom.
++0 < S 0:0(0) win 65535 <mss 48,nop,wscale 8>
++0 > S. 0:0(0) ack 1 <...>
++0 < . 1:1(0) ack 1 win 65535
++0 accept(3, ..., ...) = 4
+
+// 3. Inject 100 bytes.
+// 100 is > 48, so this forces tcp_measure_rcv_mss() to recalculate the scaling ratio.
+// Because the payload (100B) is small compared to the sk_buff truesize,
+// kernels without the fix will incorrectly drop the scaling_ratio.
++0.1 < P. 1:101(100) ack 1 win 65535
++0 > . 1:1(0) ack 101 <...>
+
+// 4. Inject 110 bytes to bypass the length jitter optimization and force
+// a second recalculation, driving the scaling_ratio to 1 and crushing the clamp.
++0.1 < P. 101:211(110) ack 1 win 65535
++0 > . 1:1(0) ack 211 <...>
+
+// 5. Assert the window clamp (tcpi_rcv_ssthresh) is protected from the penalty.
++0.1 %{
+assert tcpi_rcv_ssthresh > 15000, f"BUG DETECTED: scaling_ratio crushed! rcv_ssthresh={tcpi_rcv_ssthresh}"
+}%
--
2.53.0


  parent reply	other threads:[~2026-05-04 14:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-04 14:49 [PATCH net v2 0/2] tcp: protect locked SO_RCVBUF from Silly Window Syndrome Ankit Jain
2026-05-04 14:49 ` [PATCH net v2 1/2] " Ankit Jain
2026-05-04 16:09   ` Eric Dumazet
2026-05-05 18:19     ` Ankit Jain
2026-05-04 14:49 ` Ankit Jain [this message]
2026-05-04 16:13   ` [PATCH net v2 2/2] selftests/net: add packetdrill test for locked SO_RCVBUF SWS Eric Dumazet
2026-05-05 18:23     ` Ankit Jain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260504144945.13477-3-ankit-aj.jain@broadcom.com \
    --to=ankit-aj.jain@broadcom.com \
    --cc=ajay.kaher@broadcom.com \
    --cc=alexey.makhalov@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=karen.badiryan@broadcom.com \
    --cc=kuba@kernel.org \
    --cc=kuniyu@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=quic_stranche@quicinc.com \
    --cc=quic_subashab@quicinc.com \
    --cc=shuah@kernel.org \
    --cc=tapas.kundu@broadcom.com \
    --cc=vamsi-krishna.brahmajosyula@broadcom.com \
    --cc=yin.ding@broadcom.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox