On Wed, May 20, 2026 at 12:24 AM Laurent Vivier <[email protected]> wrote: > > On 5/20/26 06:39, Eric Dumazet wrote: > > On Tue, May 19, 2026 at 7:03 PM Jakub Kicinski <[email protected]> wrote: > >> > >> On Mon, 18 May 2026 20:34:22 +0200 Stefano Brivio wrote: > >>> Stefano Brivio (2): > >>> tcp: Don't accept data when socket is in repair mode > >> > >> Not sure Eric is on board with this patch in the first place. > >> Sound like it's not the intended use case for REPAIR so IMO > >> it's up to TCP maintainers whether we want to support this. > >> And it's definitely not a Fix. > > > > I am not on board. Only net-next material for sure. > > > > While v2 is slightly better, we have the fundamental problem of adding > > stuff to TCP receive path for features that almost nobody use. > > (It took more than 13 years to finally complain about the race) > > > > This consumes Gigawats of power on our planet (and tons of CO2), given > > the trillions of packets processed every second. > > > > Please at least add a static key as we did in: > > > > commit 020e71a3cf7f50c0f2c54cf2444067b76fe6d785 > > Author: Eric Dumazet <[email protected]> > > Date: Mon Oct 25 09:48:24 2021 -0700 > > > > ipv4: guard IP_MINTTL with a static key > > > > RFC 5082 IP_MINTTL option is rarely used on hosts. > > > > > > But in my original feedback I pointed that we TCP_REPAIR should > > probably only insert a TCP socket into TPC established hash table > > only when it is ready to process incoming packets. > > The problem is on the source side of the migration and I think removing the > socket from > the ehash table would trigger RSTs, closing the connection on the remote side.
RST is triggered anyway if TCP_REPAIR did not occur yet. This is why a netfilter solution is generally used to make sure no incoming packet is received until the whole state has been repaired.
