On Fri, Feb 20, 2026 at 12:56 AM Simon Baatz via B4 Relay <[email protected]> wrote: > > Hi, > > this series implements the receiver-side requirements for TCP window > retraction as specified in RFC 7323 and adds packetdrill tests to > cover the new behavior. > > It addresses a regression with somewhat complex causes; see my message > "Re: [regression] [PATCH net-next 7/8] tcp: stronger sk_rcvbuf checks" > (https://lkml.kernel.org/netdev/[email protected]/). > > Please see the first patch for background and implementation details. > > This is an RFC because a few open questions remain: > > - Placement of the new rcv_mwnd_seq field in tcp_sock: > > rcv_mwnd_seq is updated together with rcv_wup and rcv_wnd in > tcp_select_window. However, rcv_wup is documented as RX read_write > only (even though it is updated in tcp_select_window), and rcv_wnd > is TX read_write / RX read_mostly. > > rcv_mwnd_seq is only updated in tcp_select_window and, as far as I > can tell, is not used on the RX fast path. > > If I understand the placement rules correctly, this means that > rcv_mwnd_seq, rcv_wup, and rcv_wnd end up in different cacheline > groups, which feels odd. Guidance on where rcv_mwnd_seq should live > would be appreciated. > > - In tcp_minisocks.c, it is not clear to me whether we should change > "tcptw->tw_rcv_wnd = tcp_receive_window(tp)" to > "tcptw->tw_rcv_wnd = tcp_max_receive_window(tp)". I could not find a > case where this makes a practical difference and have left the > existing behavior unchanged. > > - Packetdrill tests: Some of these seem rather brittle to me; I > included them mostly to document what I have tested. Suggestions > for making them more robust are welcome. > > - MPTCP seems to modify tp->rcv_wnd of subflows. I haven't looked at > this, since I wanted to get feedback on the overall approach first. > > - Although this series addresses a regression triggered by commit > d2fbaad7cd8 ("tcp: stronger sk_rcvbuf checks") the underlying > problem is shrinking the window. Thus I added "Fixes" headers for > the commits that introduced window shrinking. > > I would appreciate feedback on the overall approach and on these > questions. >
Hi Simon, thanks for the clean series. I would guess you use some AI ? This is fine, just curious. Can you add more tests, in memory stress situations ? Like : A receiver grew the RWIN over time up to 8 MB. Then the application (or the kernel under stress) used SO_RCVBUF to 16K. I want to make sure the socket wont accept packets to fill the prior window and consume 8MB 8MB seems fine, unless the host has 100,000 sockets in the same situation. Thanks > Signed-off-by: Simon Baatz <[email protected]> > --- > Simon Baatz (4): > tcp: implement RFC 7323 window retraction receiver requirements > selftests/net: packetdrill: add tcp_rcv_wnd_shrink_nomem.pkt > selftests/net: packetdrill: add tcp_rcv_wnd_shrink_allowed.pkt > selftests/net: packetdrill: add tcp_rcv_toobig_back_to_back.pkt > > .../networking/net_cachelines/tcp_sock.rst | 1 + > include/linux/tcp.h | 1 + > include/net/tcp.h | 14 +++ > net/ipv4/tcp_fastopen.c | 1 + > net/ipv4/tcp_input.c | 6 +- > net/ipv4/tcp_minisocks.c | 1 + > net/ipv4/tcp_output.c | 12 +++ > .../net/packetdrill/tcp_rcv_big_endseq.pkt | 2 +- > .../packetdrill/tcp_rcv_toobig_back_to_back.pkt | 27 +++++ > .../net/packetdrill/tcp_rcv_wnd_shrink_allowed.pkt | 35 +++++++ > .../net/packetdrill/tcp_rcv_wnd_shrink_nomem.pkt | 109 > +++++++++++++++++++++ > 11 files changed, 206 insertions(+), 3 deletions(-) > --- > base-commit: 8bf22c33e7a172fbc72464f4cc484d23a6b412ba > change-id: 20260220-tcp_rfc7323_retract_wnd_rfc-c8a2d2baebde > > Best regards, > -- > Simon Baatz <[email protected]> > >
