netdev - Re: circular locking, mirred, 2.6.24.2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080306221253.GD2876@ami.dom.local>
Date:	Thu, 6 Mar 2008 23:12:53 +0100
From:	Jarek Poplawski <jarkao2@...il.com>
To:	jamal <hadi@...erus.ca>
Cc:	Denys Fedoryshchenko <denys@...p.net.lb>, netdev@...r.kernel.org
Subject: Re: circular locking, mirred, 2.6.24.2

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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html