[ofa-general] Re: 2.6.30.1: possible irq lock inversion dependency detected

Bart Van Assche bart.vanassche at gmail.com
Sat Jul 11 03:43:19 PDT 2009


On Fri, Jul 10, 2009 at 10:42 PM, Roland Dreier<rdreier at cisco.com> wrote:
>
>  > Thanks for the patch. With the patch applied the lockdep warning
>  > indeed occurs sooner and the output is now indeed shorter. You can
>  > find the new lockdep output here:
>  > http://bugzilla.kernel.org/attachment.cgi?id=22305.
>
> Thanks, that actually looks like a completely different issue (that I
> can actually understand).  I was able to reproduce that here: the issue
> is doing skb_orphan() inside of priv->lock, and the network stack
> locking is not irq-safe.  So the following hacky patch fixes that.
>
> This would be a short-term solution for the immediate issue at least.  A
> better solution would be if we didn't need to make priv->lock
> hardirq-safe: the only place that requires it is the QP event handler in
> ipoib_cm.c, and that might be a little dicy to fix.  Need to think about that.
>
> However with this patch applied I don't see any further lockdep reports
> here.  It would be great if you could retest yet again with this applied
> (on top of my earlier patch to make priv->lock hardirq-safe as early as
> possible).

With the two patches applied on top of 2.6.31.1 lockdep stopped
complaining on my setup. By the way, do you know whether this is a
long-standing issue or a result of the changes between 2.6.29 and
2.6.30 ?

Bart.



More information about the general mailing list