LOR route vr0
rwatson at FreeBSD.org
Thu Sep 1 02:41:21 GMT 2005
On Wed, 31 Aug 2005, Don Lewis wrote:
> If you are finding that you need to wire the order of if_addr_mtx, that
> is a potential clue. The only lock I see taken after if_addr_mtx is
> "UMA zone". If you are seeing other locks under if_addr_mtx, maybe one
> of those is looping back to rtentry. I also see taskqueue, "if send
> queue", and various memory subsystem locks under "network driver".
> Both taskqueue and "if send queue" appear to be leaf locks.
In the link layer multicast address code, I'm fairly careful not to hold
if_addr_mtx over calls into the ifnet code. Three suspect points are the
call to ifp->if_resolvemulti(), which looks like it is OK for all current
implementations, and the call to rt_newmaddrmsg() in if_addmulti(), which
is made before the unlock call so that the 'ifma' reference remains valid,
and a similar call to rt_newmaddrmsg() in if_delmulti(). These calls
should acquire only mbuf allocator and general allocator locks, and the
netisr handoff mutex for NETISR_ROUTE. However, perhaps there's a case
here I'm not seeing. It might be worth commenting out those two calls
under if_addr_mtx and seeing if the lock order warning goes away.
Robert N M Watson
More information about the freebsd-current