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: <20080307083251.GB3912@ff.dom.local>
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