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.
Thanks,
Laurent
