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: <20080306233151.M43262@visp.net.lb>
Date:	Fri, 7 Mar 2008 01:43:33 +0200
From:	"Denys Fedoryshchenko" <denys@...p.net.lb>
To:	jamal <hadi@...erus.ca>, Jarek Poplawski <jarkao2@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: circular locking, mirred, 2.6.24.2

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 majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ