Re: ipoib lockdep warning

[Michael S. Tsirkin]

Quoting r. Zach Brown <zach.brown@xxxxxxxxxx>:
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/