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 }%
// 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
+.1 %{ assert tcpi_state == TCP_CLOSE, tcpi_state }%
Then add my
Reviewed-by: Eric Dumazet <[email protected]>
