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
next prev 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