RE: [PATCH 2/2] Rescan the hash2 list if the hash chains have got cross-linked.

[David Laight <David.Laight@ACULAB.COM>]

From: Eric Dumazet
> Sent: 26 July 2023 15:22
...
> Can you describe what user space operation is done by your precious application,
> triggering a rehash in the first place ?

We've no idea what is causing the rehash.
There are a lot of sockets that are receiving RTP audio.
But they are only created, bound and then deleted.

The 'best guess' is something to do with ipsec tunnels
being created, deleted or rehashed.

> 
> Maybe we can think of something less disruptive in the kernel.
> (For instance, you could have a second socket, insert it in the new bucket,
> then remove the old socket)
> 
> > The problem is that a single 'port unreachable' can be treated
> > as a fatal error by the receiving application.
> > So you really don't want to be sending them.
> 
> Well, if your application needs to run with old kernels, and or
> transient netfilter changes (some firewall setups do not use
> iptables-restore)
> better be more resilient to transient ICMP messages anyway.

This is being done for the specific pair of sockets that caused grief.
For this setup they were on 127.0.0.1 but that isn't always true.
But they would be expected to be on a local network.

Reading between the lines of the comment in ipv4/icmp.c
it is reasonable to assume that ICMP_PORT_UNREACH be treated
as a fatal error (ie not a transient one).
So really the Linux kernel ought to try quite hard to not
generate them when the port exists.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)