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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
