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  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:	Fri, 7 Mar 2008 08:32:51 +0000
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 Fri, Mar 07, 2008 at 07:51:13AM +0000, Jarek Poplawski wrote:
...
> I've to find first what really bothers lockdep here, and why this
> queue_lock vs. ingress_lock order isn't reported "by default". But if
> this really is like it looks now, then it seems before doing this
> ingress "future point" some change in locking could be necessary.
> (Maybe even sooner if lockdep finds something real after this current
> patch to ifb.)

Actually, I got it a bit wrong: "the problem" with ifb could probably
exist now: if we would redirect e.g. from ifb0's ingress to eth0's
egress, while doing the same thing from eth0 to ifb0. But can we get
any traffic on ifb0's ingress? And why would we do this after all?

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

Powered by blists - more mailing lists