LOR in ip6_output() and MLDv2

[Bruce Simpson]

Hi all,

There is a Lock Order Reversal in ip6_output(), which is triggered by 
the MLDv2 code.  What's the best way to resolve?

IF_AFDATA_LOCK could be changed to an rwlock, that might help get rid of 
it -- ip6_output() will take an exclusive lock by way of in6_setscope(), 
which is needed as ip6_output() does not accept an ifp. in6_setscope() 
acquires the IF_AFDATA_LOCK and the SCOPE6_LOCK. It does not write to 
anything.

MLD tries to side-step the use of in6_setscope() with the MLD lock held, 
but this is not enough because ip6_output() will still need to call 
in6_setscope() to verify the scope ID which MLD gives to it is not bogus 
(even though in the KAME stack, this just amounts to an embedded ifindex).

The LOR is probably benign, but it exists because the bottom half of 
IPv6 is taking mutex locks on ifnet's if_afdata field. It is triggered 
because <domain>_domifattach() is always called with the IF_AFDATA lock 
held, and it takes the MLI_LOCK during initialization. WITNESS sees this 
lock order and notes it down, it then triggers a LOR on if detach.

I'd rather not introduce a netisr for an output queue, as forcing 
deferred dispatch (to get away from the LOR) is undesirable and could 
lead to further races on VIMAGE detach, for example.

cheers,
BMS