Hi Eric,
On Sat, Mar 14, 2026 at 04:58:28AM +0100, Eric Dumazet wrote:
> On Wed, Mar 11, 2026 at 12:09???AM Simon Baatz <[email protected]> wrote:
> >
> > Hi Eric,
> >
> > On Tue, Mar 10, 2026 at 09:54:58AM +0100, Eric Dumazet wrote:
> > > On Mon, Mar 9, 2026 at 9:03???AM Simon Baatz via B4 Relay
> > > <[email protected]> wrote:
> > > >
> > > > From: Simon Baatz <[email protected]>
> > > >
> > > > The test ensures we correctly apply the maximum advertised window limit
> > > > when rcv_nxt advances past rcv_mwnd_seq, so that the "usable window"
> > > > is properly clamped to zero rather than becoming negative.
> > > >
> > > > Signed-off-by: Simon Baatz <[email protected]>
> > > > ---
> > > > .../net/packetdrill/tcp_rcv_neg_window.pkt | 26
> > > > ++++++++++++++++++++++
> > > > 1 file changed, 26 insertions(+)
> > > >
> > > > diff --git
> > > > a/tools/testing/selftests/net/packetdrill/tcp_rcv_neg_window.pkt
> > > > b/tools/testing/selftests/net/packetdrill/tcp_rcv_neg_window.pkt
> > > > new file mode 100644
> > > > index
> > > > 0000000000000000000000000000000000000000..15a9b4938f16d175ac54f3fd192ed2b59b0a4399
> > > > --- /dev/null
> > > > +++ b/tools/testing/selftests/net/packetdrill/tcp_rcv_neg_window.pkt
> > > > @@ -0,0 +1,26 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +
> > > > +--mss=1000
> > > > +
> > > > +`./defaults.sh`
> > > > +
> > > > +// Establish a connection.
> > > > + +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
> > > > + +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> > > > + +0 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [20000], 4) = 0
> > > > + +0 bind(3, ..., ...) = 0
> > > > + +0 listen(3, 1) = 0
> > > > +
> > > > + +0 < S 0:0(0) win 32792 <mss 1000,nop,wscale 7>
> > > > + +0 > S. 0:0(0) ack 1 win 18980 <mss 1460,nop,wscale 0>
> > > > + +.1 < . 1:1(0) ack 1 win 257
> > > > +
> > > > + +0 accept(3, ..., ...) = 4
> > > > +
> > > > +// A too big packet is accepted if the receive queue is empty
> > > > + +0 < P. 1:20001(20000) ack 1 win 257
> > >
> > > We do not see the answer, it seems this test is not complete ?
> >
> > Actually we do not want to see an answer. The packet won't trigger
> > an immediate ACK (it is larger than the advertised window, but does
> > not cause immediate memory pressure).
> >
> > When we then send a RST before the delayed ACK would be generated:
> >
> > > > +// Send a RST immediately so that there is no rcv_wup/rcv_mwnd_seq
> > > > update yet
> > > > + +0 < R. 20001:20001(0) ack 1 win 257
> >
> > We are in a state where rcv_wup, rcv_wnd, and rcv_mwnd_seq have not
> > been updated yet, but we must still accept the RST
> > (rcv_nxt == 20001 > rcv_mwnd_seq, tcp_max_receive_window() == 0)
> >
> > > > +
> > > > + +.1 %{ assert tcpi_state == TCP_CLOSE, tcpi_state }%
> >
> > And we verify that we accepted the RST here.
> >
> > Given how subtle this sequence is, and considering the limited value
> > of this test, I am also fine with dropping it if it is too fragile or
> > confusing.
>
> Sorry I missed your answer.
>
> Ok then please use :
>
> // A too big packet is accepted if the receive queue is empty
> +0 < P. 1:20001(20000) ack 1 win 257
> +0 %{ assert tcpi_bytes_received == 20000, tcpi_bytes_received;
> assert tcpi_bytes_acked == 0, tcpi_bytes_acked }%
Unfortunately, tcpi_bytes_acked is the TX direction, it will always
be 0 here.
Instead, we can still test that the oversized packet is accepted and
indirectly verify that no immediate ACK is sent by eliciting and
checking a RST:
// A too big packet is accepted if the receive queue is empty, but does not
trigger
// an immediate ACK.
+0 < P. 1:20001(20000) ack 1 win 257
+0 %{ assert tcpi_bytes_received == 20000, tcpi_bytes_received; }%
// Send a RST immediately so that there is no rcv_wup/rcv_mwnd_seq update yet
+0 < R. 20001:20001(0) ack 1 win 257
// Verify that the RST was accepted. Indirectly this also verifies that no
immediate
// ACK was sent for the data packet above.
+0 < . 20001:20001(0) ack 1 win 257
* > R 1:1(0)
As the series is merged now (thank you!), I will send this
separately, as suggested.
- Simon
--
Simon Baatz <[email protected]>
