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 On Wed, Jul 20, 2016 at 1:29 PM, Ryan Stone <[email protected]> wrote: > I've hit a dilemma in a fix I have in review[1]. Currently, in_broadcast() > iterates over the ifnet address list without holding any locks. I can > pretty easily panic the kernel by constantly adding and removing addresses > while passing traffic over the interface. The fix is to acquire the > appropriate rlock, but the catch is that according to dtrace, > in_broadcast() is called on almost every packet that passes through > ip_output(). I'm concerned about adding additional locking operations to > the transmit path. > > Do we actually need to call in_broadcast() so often? It seems silly to > check whether we are sending to a broadcast address on a per-packet basis. > > > [1] https://reviews.freebsd.org/D7227 > _______________________________________________ > [email protected] mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-transport > To unsubscribe, send any mail to " > [email protected]" > _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-transport To unsubscribe, send any mail to "[email protected]"
