On Tue, 2006-11-21 at 12:05 -0600, Larry Finger wrote: > Although my understanding of locking has been shown to be deficient, it looks to me as if the > deadlock involves a WX call while a scan is in progress. The following patch uses > mutex_trylock rather than mutex_lock so that WX calls are rejected if the lock is already held. > Please try this patch with wpa_supplicant and NetworkManager both running. I have tested it with > wpa_supplicant alone. I don't think this is the right thing to do. This cannot be causing the deadlock as for a deadlock you need (at least) two locks. Now, since any calls from userspace to d80211 acquire the mutex first, they should be fine. They also both acquire the rtnl lock first. The deadlock must be somewhere deeper. Can we run this with lockdep enabled? Might give us a hint before we dig out all the used locks here... johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
- Follow-Ups:
- References:
- Prev by Date: Re: Problem with DMA on x86_64 with 3 GB RAM
- Next by Date: Re: [kvm-devel] [PATCH] KVM: Avoid using vmx instruction directly
- Previous by thread: Re: RFC/T: Trial fix for the bcm43xx - wpa_supplicant - NetworkManager deadlock
- Next by thread: Re: RFC/T: Trial fix for the bcm43xx - wpa_supplicant - NetworkManager deadlock
- Index(es):