aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
diff options
context:
space:
mode:
authorJarek Poplawski <jarkao2@gmail.com>2008-03-20 20:05:13 -0400
committerDavid S. Miller <davem@davemloft.net>2008-03-20 20:05:13 -0400
commit94833dfb8c98ed4ca1944dd2c1339d88a2d1c758 (patch)
treec059b5aec8432d82c73f1f3038132f364502d265 /drivers
parent38fe999e2286139cccdaa500a81bd49a16a81158 (diff)
[NET] ifb: set separate lockdep classes for queue locks
[ 10.536424] ======================================================= [ 10.536424] [ INFO: possible circular locking dependency detected ] [ 10.536424] 2.6.25-rc3-devel #3 [ 10.536424] ------------------------------------------------------- [ 10.536424] swapper/0 is trying to acquire lock: [ 10.536424] (&dev->queue_lock){-+..}, at: [<c0299b4a>] dev_queue_xmit+0x175/0x2f3 [ 10.536424] [ 10.536424] but task is already holding lock: [ 10.536424] (&p->tcfc_lock){-+..}, at: [<f8a67154>] tcf_mirred+0x20/0x178 [act_mirred] [ 10.536424] [ 10.536424] which lock already depends on the new lock. lockdep warns of locking order while using ifb with sch_ingress and act_mirred: ingress_lock, tcfc_lock, queue_lock (usually queue_lock is at the beginning). This patch is only to tell lockdep that ifb is a different device (e.g. from eth) and has its own pair of queue locks. (This warning is a false-positive in common scenario of using ifb; yet there are possible situations, when this order could be dangerous; lockdep should warn in such a case.) (With suggestions by David S. Miller) Reported-and-tested-by: Denys Fedoryshchenko <denys@visp.net.lb> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> Acked-by: Jamal Hadi Salim <hadi@cyberus.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers')
-rw-r--r--drivers/net/ifb.c15
1 files changed, 15 insertions, 0 deletions
diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index 15949d3df17e..af233b591534 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c
@@ -35,6 +35,7 @@
35#include <linux/moduleparam.h> 35#include <linux/moduleparam.h>
36#include <net/pkt_sched.h> 36#include <net/pkt_sched.h>
37#include <net/net_namespace.h> 37#include <net/net_namespace.h>
38#include <linux/lockdep.h>
38 39
39#define TX_TIMEOUT (2*HZ) 40#define TX_TIMEOUT (2*HZ)
40 41
@@ -227,6 +228,16 @@ static struct rtnl_link_ops ifb_link_ops __read_mostly = {
227module_param(numifbs, int, 0); 228module_param(numifbs, int, 0);
228MODULE_PARM_DESC(numifbs, "Number of ifb devices"); 229MODULE_PARM_DESC(numifbs, "Number of ifb devices");
229 230
231/*
232 * dev_ifb->queue_lock is usually taken after dev->ingress_lock,
233 * reversely to e.g. qdisc_lock_tree(). It should be safe until
234 * ifb doesn't take dev->queue_lock with dev_ifb->ingress_lock.
235 * But lockdep should know that ifb has different locks from dev.
236 */
237static struct lock_class_key ifb_queue_lock_key;
238static struct lock_class_key ifb_ingress_lock_key;
239
240
230static int __init ifb_init_one(int index) 241static int __init ifb_init_one(int index)
231{ 242{
232 struct net_device *dev_ifb; 243 struct net_device *dev_ifb;
@@ -246,6 +257,10 @@ static int __init ifb_init_one(int index)
246 err = register_netdevice(dev_ifb); 257 err = register_netdevice(dev_ifb);
247 if (err < 0) 258 if (err < 0)
248 goto err; 259 goto err;
260
261 lockdep_set_class(&dev_ifb->queue_lock, &ifb_queue_lock_key);
262 lockdep_set_class(&dev_ifb->ingress_lock, &ifb_ingress_lock_key);
263
249 return 0; 264 return 0;
250 265
251err: 266err: