[PATCH net 0/2] udp: two fixes for the 4-tuple hash table

[Shardul Bankar]

Two ways a UDP socket ends up in the wrong place in the 4-tuple hash table.
The patches are independent, with different Fixes: tags and no dependency
between them.

Patch 1: a socket that connects a second time is not relocated, so it stays
filed under its first peer's hash and packets for it fall back to scoring
the hash2 chain for its address and port.

Patch 2: a socket bound to a specific address and port is not taken out of
the table when it disconnects, because __udp_disconnect() only does that
via ->rehash() or ->unhash() and neither runs for it.

Both are in code shared by IPv4 and IPv6.

Patch 1's cost, with N sockets sharing a port and one of them misfiled,
200k packets sent to its 4-tuple:

	N	without		with
	200	1,061,652	2,093,259 pps
	500	  522,553	2,055,078 pps
	1000	  279,729	2,136,606 pps

Correctly filed sockets measure ~2.1M pps throughout, so the cost scales
with the number of sockets on the port, as the fallback scan does. For
comparison, commit 78c91ae2c6de ("ipv4/udp: Add 4-tuple hash for connected
socket") measured 290,860 pps without the table and 1,889,658 with it at
500 connected sockets.

Patch 2's cost is not in throughput. Its stale entry keeps hash4_cnt raised
for the life of the socket, so every packet for that address and port is
sent through the 4-tuple lookup first; on IPv6 the entry is also matchable,
because __udp_disconnect() does not clear sk_v6_daddr. That last one is a
separate defect, which I will send on its own.

Neither patch has a selftest. Nothing in tree reports which 4-tuple bucket
a socket is filed under, so a test can only measure the cost indirectly.
What I did instead was add pr_info() to the hash4 paths and a knob that
dumps bucket occupancy, then run the same scenarios on two kernels
differing only by these patches; that is where the numbers above come from.
The instrumentation, the reproducers and the benchmark are at [1]. If
exposing the bucket through diag would be welcome, that would make both
defects testable in tree and I am glad to do it for net-next.

Removing the connect(AF_UNSPEC) limitation described in 644f9108f3a5 is a
side effect of patch 1 fixing the general case. I can make it narrower if
you would rather that limitation stayed.

Tooling, per Documentation/process/generated-content.rst: this series was
developed in an assisted session with an LLM. The assistant did most of
the code reading, wrote the instrumentation and reproducers behind [1],
drafted these changelogs, and ran the A/B builds and the regression
suites below. Every claim in these messages was checked against the
source, and the IPv6 behaviour described in patch 2 was confirmed at
runtime.

Tested on x86-64, IPv4 and IPv6. No regressions across reuseport_bpf,
reuseport_bpf_cpu, reuseport_addr_any.sh, reuseport_dualstack,
udpgso_bench.sh, udpgro_bench.sh and socket.

[1] https://github.com/shardulsdk-mpiric/linux/tree/udp-hash4-fix-verification

To: Willem de Bruijn <willemdebruijn.kernel@xxxxxxxxx>
To: "David S. Miller" <davem@xxxxxxxxxxxxx>
To: Eric Dumazet <edumazet@xxxxxxxxxx>
To: Jakub Kicinski <kuba@xxxxxxxxxx>
To: Paolo Abeni <pabeni@xxxxxxxxxx>
To: Simon Horman <horms@xxxxxxxxxx>
To: Philo Lu <lulie@xxxxxxxxxxxxxxxxx>
To: Fred Chen <fred.cc@xxxxxxxxxxxxxxx>
To: Yubing Qiu <yubing.qiuyubing@xxxxxxxxxxxxxxx>
Cc: Kuniyuki Iwashima <kuniyu@xxxxxxxxxx>
Cc: Willem de Bruijn <willemb@xxxxxxxxxx>
Cc: Cambda Zhu <cambda@xxxxxxxxxxxxxxxxx>
Cc: Janak Bhatt <janak@xxxxxxxxx>
Cc: Kalpan Jani <kalpan.jani@xxxxxxxxxxxxxxxxxx>
Cc: Shardul Bankar <shardulsb08@xxxxxxxxx>
Cc: netdev@xxxxxxxxxxxxxxx
Cc: linux-kernel@xxxxxxxxxxxxxxx

Signed-off-by: Shardul Bankar <shardul.b@xxxxxxxxxxxxxxxxxx>
---
Shardul Bankar (2):
      udp: relocate a connected socket in the 4-tuple hash table on re-connect
      udp: remove a disconnected socket from the 4-tuple hash table

 net/ipv4/udp.c | 42 +++++++++++++++++++++++++++++++++++++-----
 1 file changed, 37 insertions(+), 5 deletions(-)
---
base-commit: c9151088f1674fd29ff26a20f5fc687acf53a2f0
change-id: 20260911-udp_hash4_fix_v1-ac7e020d4089

Best regards,
--  
Shardul Bankar <shardul.b@xxxxxxxxxxxxxxxxxx>