Subject: Re: circular locking, mirred, 2.6.24.2

From: "Denys Fedoryshchenko" <[email-masked]>
Date: Fri, 7 Mar 2008 01:43:33 +0200

About reproducing, I think .config matter
Mine is at http://www.nuclearcat.com/files/config.txt

About hardware, maybe it is important - it is Intel dual core machine (32-
bit). I test few more times, i can reproduce it for sure. It gives lockdep on 
first incoming packet.

More info about hardware:
CPU model name      : Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz
Other machines where i get this lockdep also Core Duo CPU's. 
I test now on old 2xXeon,P4 with hyperthreading - also triggered.

Shortest script i use:
modprobe ifb
ifconfig ifb0 up
/sbin/tc qdisc del dev eth0 ingress 1>/dev/null 2>/dev/null
/sbin/tc qdisc add dev eth0 ingress
/sbin/tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 \
         match u32 0 0 flowid 1:1 \
         action mirred egress redirect dev ifb0

On Thu, 6 Mar 2008 23:12:53 +0100, Jarek Poplawski wrote
> 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 [email-masked]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.