On Wed, Jul 20, 2016 at 3:00 PM, Drew Gallatin <[email protected]> wrote:
> I'd certainly prefer not to add any overhead. Properly managing this (and > other similar) lists is a job for some lightweight lifecycle based > mechanism like concurrency kit or rcu. > > Unless you have a solid reason to fix it, I'd suggest just adding the > locking commented out (the way rwatson did with IN_IFADDR_RLOCK in > ip_input(), so that the next person to trip over it will know what's going > on. > > Drew > I'm not clear on the details, but we have some internal tests that were provoking this exact crash after a couple of days of stress testing. I believe that the actual fix would involve caching the result in the pcb. When the endpoint is already known, there's no reason to check for a broadcast packet on every single packet. On a system that uses a large number of IP addresses on an interface (e.g. for jails) the overhead of just iterating over the list is going to add up no matter what synchronization mechanism you use. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-transport To unsubscribe, send any mail to "[email protected]"
