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 for Android: free password hash cracker in your pocket

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

Message-Id: <20080306143910.M91001@visp.net.lb>
Date:	Thu, 6 Mar 2008 17:50:59 +0200
From:	"Denys Fedoryshchenko" <denys@...p.net.lb>
To:	hadi@...erus.ca
Cc:	Jarek Poplawski <jarkao2@...il.com>, netdev@...r.kernel.org
Subject: Re: circular locking, mirred, 2.6.24.2

On Thu, 06 Mar 2008 09:27:14 -0500, jamal wrote
> On Thu, 2008-06-03 at 15:57 +0200, Denys Fedoryshchenko wrote:
> > I am able to reproduce this warning over this relatively simple shell 
script
> > on my Gentoo PC (2.6.25-rc3).
> > http://www.nuclearcat.com/files/bug_feb.txt
> >
> 
> That script looks pretty sane to me - nothing super-exciting. I suspect
> you eventually want them all to look like ifb1 on the egress.
> Do you see the same issue without the ifb1 speacial case?
Well, i am able to reproduce in much more trivial script. Tested 2.6.25-rc4 
also.

modprobe ifb
ifconfig ifb0 up
TC=/sbin/tc
$TC qdisc del dev eth0 ingress 1>/dev/null 2>/dev/null
$TC qdisc add dev eth0 ingress
${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

> 
> > Probably it will help to debug issue for more experienced developers. 
Note:
> > it appears not immediately, second time i tested, it's appeared after 
while,
> > but in matter of seconds.
> 
> I wonder is there some latency from the moment you insmod ifb to the
> moment the tc rules take effect? Will it still happen if you dont 
> have modules? Also note, that lock dependency is a bit strange,
>  Jarek correct me if i am wrong; it seems to say: a packet received 
> on ingress of some e1000 (ethx) gets acted on by mirred which ends 
> grabbing lock of an ifb device - this part should be fine and no 
> need for the alarm. The alarm seems to be a result of a loopback 
> device that is being registered in between the two activities.
> i.e there are three devices affected with entirely different 
> locks(ethx, ifbx, and loopback). Smells like lockdep is getting it wrong?
No idea, i have strange lockup's on my systems where i have ifb, and that 
make me worry. And i feel it is directly related with my love to use ifb 
devices and way how i am using them.

> 
> > Note - it can stop traffic on PC completely. It is also seems crashed my 
> > desktop PC, i am not able to execute "tc qdisc del dev eth0 root".
> > The system hang completely. I had few similar issues on my PPPoE servers 
> > (with different scripts for shapers), that system hang, and even "reboot -
f" 
> > doesn't work sometimes.
> 
> This sounds like a different issue from above - when did this start 
> to happen? Is it at the same time as above warnings showing up?

Yes, it is different issue seems, it is rare to lockup system , and i will 
dig more, to understand how it is happening.

> 
> cheers,
> jamal
> 
> --
> 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