Re: 26-rc9-mmotm lockdep warning initializing loopback interface

From: Andrew Morton
Date: Mon Jul 14 2008 - 00:08:41 EST


On Sun, 13 Jul 2008 06:00:03 -0400 Valdis.Kletnieks@xxxxxx wrote:

> I wonder if it's this chunk in linux-next.patch:
>
> void qdisc_lock_tree(struct net_device *dev)
> - __acquires(dev->queue_lock)
> - __acquires(dev->ingress_lock)
> + __acquires(dev->tx_queue.lock)
> + __acquires(dev->rx_queue.lock)
> {
> - spin_lock_bh(&dev->queue_lock);
> - spin_lock(&dev->ingress_lock);
> + spin_lock_bh(&dev->tx_queue.lock);
> + spin_lock(&dev->rx_queue.lock);
> }
>
> For loopback, is tx_queue the same as rx_queue? That would explain this..
>
> Found this in the dmesg:
>
> [ 0.418581] system 00:0b: iomem range 0xfed00000-0xfed003ff has been reserved
> [ 0.421109]
> [ 0.421110] =============================================
> [ 0.421123] [ INFO: possible recursive locking detected ]
> [ 0.421132] 2.6.26-rc9-mm1 #2
> [ 0.421138] ---------------------------------------------
> [ 0.421147] swapper/1 is trying to acquire lock:
> [ 0.421154] (&queue->lock){-...}, at: [<ffffffff804b81d5>] qdisc_lock_tree+0x27/0x2c
> [ 0.421176]
> [ 0.421177] but task is already holding lock:
> [ 0.421186] (&queue->lock){-...}, at: [<ffffffff804b81cd>] qdisc_lock_tree+0x1f/0x2c
> [ 0.421205]
> [ 0.421205] other info that might help us debug this:
> [ 0.421216] 3 locks held by swapper/1:
> [ 0.421221] #0: (net_mutex){--..}, at: [<ffffffff804a5557>] register_pernet_device+0x1a/0x5a
> [ 0.421245] #1: (rtnl_mutex){--..}, at: [<ffffffff804b1fe0>] rtnl_lock+0x12/0x14
> [ 0.421256] #2: (&queue->lock){-...}, at: [<ffffffff804b81cd>] qdisc_lock_tree+0x1f/0x2c
> [ 0.421256]
> [ 0.421256] stack backtrace:
> [ 0.421256] Pid: 1, comm: swapper Not tainted 2.6.26-rc9-mm1 #2
> [ 0.421256]
> [ 0.421256] Call Trace:
> [ 0.421256] [<ffffffff8025b65c>] __lock_acquire+0xd70/0x1131
> [ 0.421256] [<ffffffff804b81d5>] ? qdisc_lock_tree+0x27/0x2c
> [ 0.421256] [<ffffffff8025bac2>] lock_acquire+0xa5/0xc9
> [ 0.421256] [<ffffffff804b81d5>] ? qdisc_lock_tree+0x27/0x2c
> [ 0.421256] [<ffffffff8055e61c>] _spin_lock+0x2f/0x3b
> [ 0.421256] [<ffffffff804b81d5>] qdisc_lock_tree+0x27/0x2c
> [ 0.421256] [<ffffffff804b8217>] dev_init_scheduler+0x11/0x94
> [ 0.421256] [<ffffffff804a992e>] register_netdevice+0x2e5/0x455
> [ 0.421256] [<ffffffff804a9ad8>] register_netdev+0x3a/0x48
> [ 0.421256] [<ffffffff807a2189>] loopback_net_init+0x40/0x7a
> [ 0.421256] [<ffffffff807a2137>] ? loopback_init+0x0/0x12
> [ 0.421256] [<ffffffff804a556a>] register_pernet_device+0x2d/0x5a
> [ 0.421256] [<ffffffff807a2147>] loopback_init+0x10/0x12
> [ 0.421256] [<ffffffff80781563>] do_one_initcall+0x47/0x141
> [ 0.421256] [<ffffffff802770e8>] ? register_irq_proc+0xd3/0xef
> [ 0.421256] [<ffffffff802f0000>] ? check_idq+0xff/0x197
> [ 0.421270] [<ffffffff80781784>] kernel_init+0x127/0x17b
> [ 0.421270] [<ffffffff8055debb>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [ 0.421270] [<ffffffff8020d349>] child_rip+0xa/0x11
> [ 0.421270] [<ffffffff8025a2de>] ? trace_hardirqs_on+0xd/0xf
> [ 0.421270] [<ffffffff8020c953>] ? restore_args+0x0/0x30
> [ 0.421270] [<ffffffff8078165d>] ? kernel_init+0x0/0x17b
> [ 0.421270] [<ffffffff8020d33f>] ? child_rip+0x0/0x11
> [ 0.421270]
> [ 0.421358] pci 0000:03:01.0: BAR 9 too large: 0x00000000000000-0x00000003ffffff
> [ 0.421379] pci 0000:00:01.0: PCI bridge, secondary bus 0000:01
> [ 0.421389] pci 0000:00:01.0: IO window: disabled
> [ 0.421402] pci 0000:00:01.0: MEM window: 0xed000000-0xefefffff
> [ 0.421414] pci 0000:00:01.0: PREFETCH window: 0x000000d0000000-0x000000dfffffff

Yup, it looks like that patch might be the culprit.

commit dc2b48475a0a36f8b3bbb2da60d3a006dc5c2c84
Author: David S. Miller <davem@xxxxxxxxxxxxx>
Date: Tue Jul 8 17:18:23 2008 -0700

netdev: Move queue_lock into struct netdev_queue.

<adds cc, runs away>

(thanks for doing all this stuff, btw - it directly subtracts from the
amount of time I need to spend doing next -mm. Even better: it gives
others time to fix the things which you've found so next -mm
(mid-week?) will have lower latency and me-hassle).

(otoh, many of these problems are also in linux-next. Who's testing
that? Hopefully it's a weekend*summer thing.)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/