26-rc9-mmotm lockdep warning initializing loopback interface

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:

31 more lines

On Sun, 13 Jul 2008 06:00:03 -0400 Valdis.Kletnieks@vt.edu 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:

29 more quoted lines

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

commit dc2b48475a0a36f8b3bbb2da60d3a006dc5c2c84
Author: David S. Miller [off-list ref]
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.)

On 14-07-2008 06:07, Andrew Morton wrote:

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

...

quoted

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

...

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

http://permalink.gmane.org/gmane.linux.kernel.next/1514

Jarek P.

PS: it's only about lockdep annotation, and could be fixed with
other way finally.