Messages in this thread | | | Date | Thu, 2 Feb 2006 23:17:29 +1100 | Subject | Re: [lock validator] inet6_destroy_sock(): soft-safe -> soft-unsafe lock dependency | From | Herbert Xu <> |
| |
On Thu, Feb 02, 2006 at 11:54:29AM +0100, Ingo Molnar wrote: > > hm, i got a new one: > > ============================================ > [ BUG: circular locking deadlock detected! ] > -------------------------------------------- > sshd/28997 is trying to acquire lock: > (&sk->sk_lock.slock){-+}, at: [<c0c6be28>] packet_rcv+0xbf/0x34b > > but task is already holding lock: > (&dev->xmit_lock){-+}, at: [<c0bb04ec>] qdisc_restart+0x46/0x207 > > which lock already depends on the new lock, > which could lead to circular deadlocks! > > the dependency chain (in reverse order) is: > -> #2 (&dev->xmit_lock){-+}: [<c0bb04ec>] qdisc_restart+0x46/0x207 > -> #1 (&dev->queue_lock){-+}: [<c0b98137>] dev_queue_xmit+0xc3/0x21e > -> #0 (&sk->sk_lock.slock){-+}: [<c0c6be28>] packet_rcv+0xbf/0x34b
I believe this is a false positive and I think I can see where it went wrong. The dependency between #0 and #1 is the broken premise.
The validator is probably putting all sk_lock's in the same basket. That is, it's mixing up the socket locks for TCP, UDP as well as AF_PACKET. While it is true that TCP and UDP's sk_lock may sit outside queue_lock, AF_PACKET never transmits while holding its sk_lock.
So the #0 => #1 dependency shouldn't exist. Can you get the validator to print out the reasoning for the #0 => #1 dependency? That should clarify the problem.
Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |