>
> The model that I went with is that we don't want to hold any lock for
> protection across the call to ipsq_exit (and ipsq_enter, qwriter_ip).
> I thought you also said the same in the comments in ipsq_dq just
> before the call to the recursive ipsq_exit.
What the comment said is:
/*
* Second, exit the group xop via ipsq_exit(). This
* is safe since we're still exclusive on it. We're
* no longer holding xopipsq's ipx_lock or any of its
* ipsq locks, so there's no risk of lock recursion.
*/
> Otherwise there is the fear of recursive lock entry, if the
> 'exclusively called IP function func()' tries to become exclusive
> again. It is hard for the IPSQ framework to guess whether func() or
> any of its callees would do ipsq_try_enter(ill, ....) and on which ill
> it would try this. There is some convoluted code in optcom.c for TPI
> options which could trigger this kind of behavior. (multicast joins and
> leaves hopping from 1 ill to another).
I see. I think dropping the ill_locks don't present a problem, but the
ipsq_lock is trickier since dropping it in ipsq_dq() opens up some races.
I'll put this issue on the TODO list.
BTW, I believe I have resolved all of the other locking issues you raised
earlier. I'll send a revised webrev out once I've had a chance to test it
out more.
--
meem
