Re: circular locking, mirred, 2.6.24.2

[Jarek Poplawski <jarkao2@gmail.com>]

On Thu, Mar 06, 2008 at 03:56:40PM -0500, jamal wrote:
> On Thu, 2008-06-03 at 21:25 +0100, Jarek Poplawski wrote:
> 
> > It's really strange: I can't reproduce this, 
> 
> I couldnt either - are you using 2.6.25-rc4?

No, David's net-2.6 tree so 2.6.25-rc3 plus something...

> 
> > and if it were so easy we
> > would get really a lot of similar reports. It looks like you have
> > something special. This lockdep report with this kind of problem
> > usually looks different too. The good side is it's easy to reproduce.
> > So, could you try the patch below? (It's only supposed to fix the lockdep
> > warning, not lockups).
> 
> This is more out of ignorance: Why is ifb needing the extra teaching for
> lockdep? It is a netdevice - shouldnt the two global lockdeps you
> described earlier not be sufficient?

As I've written in the previous message, currently lockdep tracks
dev->queue_lock and dev->ingress_lock as only two locks used by all
net devices (unless they were annotated individually). So, it's like
A and B lock, and it's really not right to them AB in one place, and
BA in another. In reality each net_device's locks are independent,
so ifb has C and D. And it's not AB vs. BA, but: AB (eth/lo->queue_lock,
eth/lo->ingress_lock), CD (the same for ifb) and BC (eth/lo->ingress_lock,
ifb->queue_lock) - all legal combinations, and no inversion.

Cheers,
Jarek P.