lkml.org 
[lkml]   [2006]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [lock validator] drivers/net/8139too.c: deadlock?
Date
Francois Romieu <romieu@fr.zoreil.com> wrote:
> Ingo Molnar <mingo@elte.hu> :
> [...]
>> i'm wondering, is this a genuine deadlock, or a false positive? The
>> dependency chain is quite complex, but looks realistic:
>>
>> -> #4 {&dev->xmit_lock}: [<c045294b>] dev_watchdog+0x1b/0xc0
>> -> #3 {&dev->queue_lock}: [<c0447154>] dev_queue_xmit+0x64/0x290
>> -> #2 {&((sk)->sk_lock.slock)}: [<c043eb66>] sk_clone+0x66/0x200
>> -> #1 {&((sk)->sk_lock.slock)}: [<c047a116>] tcp_v4_rcv+0x726/0x9d0
>> -> #0 {&tp->rx_lock}: [<c033e460>] rtl8139_tx_timeout+0x110/0x1f0
>
> It looks like watchdog racing against rx_poll (which should/can not
> happen). Do you have something specific in mind ?

You've got it.

rx_poll => rtl8139_rx => netif_receive_skb => ... => tcp_v4_rcv

In fact once we're at netif_receive_skb it's easy to see how we'll grab
xmit_lock again.

Prescription: Move TX timeout handling into a work queue.

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/

\
 
 \ /
  Last update: 2006-01-27 03:24    [W:0.064 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site