Tom Uffner wrote: > > slightly different this time, but it still panics. seems to be trying > to delete nonexistent addresses. should it even be here? i don't have > any multicast addrs defined, just one dhcp-assigned unicast addr. Yup, it should be there. The IP stack will always join 224.0.0.1, this is standards compliant behaviour. Even if you have no multicast addresses explicitly configured by yourself or any application, the multicast code is always used on any system configured with INET. I believe this new patch should fix your panic. Because the hardware is being ejected, the netinet part of the stack won't see the detach first, but net will, and this is where the panic is happening. In this particular case, net is doing the cleanup because of the unexpected detach. It looks like it is the ll_ifma which is causing problems. The problem with ll_ifma is that it is also linked into the if_multiaddrs tailq; we must link AF_LINK addresses in this tailq or things like joining a link-layer group alone will not work. As such it will get seen twice by the same function but in a different role. Previously FreeBSD would just leak memory instead of panicking in situations like this. I rewrote this code to null out the ifp's when ifnet was detached, so that netinet could detect the detach of the underlying layer, and not try to reenter the net code improperly; this was particularly important to avoid bad situations with locking. If the interface needs Giant, the locking is particularly nasty. Regards, BMS
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:07 UTC