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

Powered by blists - more mailing lists