Quoting r. Zach Brown <[EMAIL PROTECTED]>: > BC: > > query_idr.lock is taken with interrupts enabled and so is implicitly > ordered before dev->_xmit_lock which is taken in interrupt context. > > ipoib_mcast_join_task() > ipoib_mcast_join() > ib_sa_mcmember_rec_query() > send_mad() > idr_pre_get(&query_idr) > spin_lock(&idp->lock)
Got to check, but if that's true we have a simple deadlock here: ib_sa_mcmember_rec_query might get called from interrupt context as well, deadlocking on idp->lock? Sean? > I can imagine all sorts of potential fixes (block ints when calling idr? > reorder acquiry in ipoib_mcast_restart_task()?) but I'm operating on a > partial view of the paths here so I wasn't comfortable suggesting a fix. > I wouldn't be surprised to hear that there are circumstances that both > lockdep and I don't know about that stop this from being a problem :). Awesome, thanks for the analysis! Your help is very much appreciated. -- MST _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
