https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292162
--- Comment #6 from Gleb Smirnoff <[email protected]> --- I agree with Kristof that this is the same bug as all other open bugs that you would find searching for in6_selecthlim in subject. The core problem is that the packet forwarding thread that catches the panic has nothing more than the network epoch for synchronization. When an interface departs, the struct ifnet and ifaddrs are freed with the epoch protection, but many protocols attached to departing ifnet are freed immediately. IPv6 is one of them. A proper fix is delayed epoch aware free of IPv6 bits. Why did the panic became easier to reproduce in CURRENT? Because my 0d469d23715d has removed extra EPOCH_DRAIN_CALLBACKS(). This call did not provide a correct protection against the panic, but it reduced its probability a lot. Why does other protocols don't panic in a similar way? Along with the epoch, we also got several relic mechanisms against interface departure races. One of the is if_dead, that a departing interface is assigned with output methods that won't dereference anything. Other is the protocols setting their ifp->if_foo softc to NULL on departure and doing a NULL check on every entry. None of these mechanisms is truly safe, but they reduce panic probabilities. I plan to look at delayed free of IPv6 bits ASAP. -- You are receiving this mail because: You are the assignee for the bug.
