On Mon, 2006-07-31 at 14:02 -0700, David Miller wrote:

From: Dave Jones <redacted>
Date: Mon, 31 Jul 2006 16:50:04 -0400

quoted

2.6.18rc2-gitSomething on my firewall box just triggered this..

Lockdep is perhaps confused.

quoted

[515613.904945] swapper/0 is trying to acquire lock:
[515613.931489]  (&tbl->lock){-+-+}, at: [<c05b5d63>] neigh_lookup+0x50/0xaf
[515613.964369] 
[515613.964373] but task is already holding lock:
[515614.006550]  (&skb_queue_lock_key){-+..}, at: [<c05b741c>] neigh_proxy_process+0x20/0xc2

The skb_queue_lock in question is &tbl->proxy_queue.lock

quoted

[515614.103459] the existing dependency chain (in reverse order) is:
[515614.148752] 
[515614.148755] -> #2 (&skb_queue_lock_key){-+..}:
[515614.188880]        [<c043bf43>] lock_acquire+0x4b/0x6c
[515614.215554]        [<c06089a7>] _spin_lock_irqsave+0x22/0x32
[515614.243606]        [<c05ac2e3>] skb_dequeue+0x12/0x43
[515614.269657]        [<c05acffe>] skb_queue_purge+0x14/0x1b
[515614.296565]        [<c05b673e>] neigh_update+0x317/0x353

This is a different queue lock, namely &neigh->arp_queue.lock

Like the ipv6 trace we got yesterday from Matt Domsche, lockdep
is aparently confusing two instances of the skb_queue_lock_key

we fixed lockdep to have this lock key to be per skb queue ... didn't
you put that patch in rawhide Dave (J) ?