LOR route vr0

[Robert Watson]

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