Hi Stefano, On Tue, Mar 10, 2026 at 09:58:07AM +0100, Stefano Brivio wrote: > Simon, > > On Mon, 09 Mar 2026 09:02:26 +0100 > Simon Baatz via B4 Relay <[email protected]> wrote: > > > [...] > > > > diff --git a/include/linux/tcp.h b/include/linux/tcp.h > > index > > f72eef31fa23cc584f2f0cefacdc35cae43aa52d..73aa2e0ccd1d7a6314a00c27950b019b62a3851c > > 100644 > > --- a/include/linux/tcp.h > > +++ b/include/linux/tcp.h > > @@ -316,6 +316,9 @@ struct tcp_sock { > > */ > > u32 app_limited; /* limited until "delivered" reaches this val */ > > u32 rcv_wnd; /* Current receiver window */ > > + u32 rcv_mwnd_seq; /* Maximum window sequence number (RFC 7323, > > + * section 2.4, receiver requirements) > > + */ > > I didn't follow the rest of the discussion but, at this point, what > does this mean for applications (CRIU, passt) dumping/restoring socket > data? Do they have to adapt? I couldn't find this bit of information > anywhere in v3.
Based on our discussion, the "Setting the TCP_REPAIR_WINDOW socket option initializes rcv_mwnd_seq" v2 change addresses TCP window restoration. As we said that information about window retraction is not crucial, the window will be restored as "non-retracted", matching prior behavior. Therefore, there is no change to the information that applications need to dump or restore. -- Simon Baatz <[email protected]>
