linux-kernel - Re: RFC/T: Trial fix for the bcm43xx - wpa_supplicant

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1164133962.3631.14.camel@johannes.berg>
Date:	Tue, 21 Nov 2006 19:32:42 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	Larry Finger <Larry.Finger@...inger.net>
Cc:	Ray Lee <ray-lk@...rabbit.org>, Dan Williams <dcbw@...hat.com>,
	Broadcom Linux <bcm43xx-dev@...ts.berlios.de>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: RFC/T: Trial fix for the bcm43xx - wpa_supplicant -
	NetworkManager deadlock

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

Download attachment "signature.asc" of type "application/pgp-signature" (191 bytes)