Meem, 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. 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).
Thirumalai Peter Memishian wrote: > > 10. ipsq_enter/ ipsq_dq() / ipsq_exit. > > > > ipsq_dq: Need to drop ipsq_lock and the ill locks before the call to > > ipsq_exit(xopipsq,... at L7617. It may be good to add some assertions > > at the top of ipsq_exit to make sure we don't hold any lock at entry > > to ipsq_exit. > >As per the comment above the ipsq_exit() call, I'm not sure why this would >be needed, since our ill and ipsq are no longer part of the group ipsq >being processed by that ipsq_exit(). > > > Need to become writer on the own xop after switching the xop > > before calling ipsq_exit() on the group xop at L7617. Otherwise nothing to > > prevent some other thread becoming writer on our xop > >I don't see how this could happen -- we've still got our IPSQ locked, so >no one should be able to access our xop before we become writer on it as >part of step (4). > > > ipsq_enter: also needs to respect the ipx_ipsq_queued > >If so, it seems like there's a bug in Nevada, since ipsq_enter() in Nevada >does not respect ipsq_xopq_mphead. (ipx_ipsq_queued is essentially a >replacement for ipsq_xopq_mphead that allows the thread to check whether >any of the IPSQ's sharing the xop have ipsq_xopq_mphead != NULL.) > > >
