Re: [panic] Race in IEEE802.11 layer towards device drivers

From: Rui Paulo <rpaulo_at_FreeBSD.org>
Date: Mon, 12 Jul 2010 17:56:28 +0100
On 12 Jul 2010, at 01:07, Andrew Thompson wrote:

> On 8 July 2010 07:13, Hans Petter Selasky <hselasky_at_c2i.net> wrote:
>> Hi,
>> 
>> When supplying wpa_supplicant.conf with incorrect passwords, but a valid SSID,
>> I have seen kernel panics several times when using USB based WLAN dongles.
>> When only supplying a valid password, no panic has been seen.
>> 
>> How to reproduce:
>> 
>> 1) configure invalid password
>> 2) wpa_cli: reconfigure
>> 3) configure valid password
>> 4) wpa_cli: reconfigure
>> 5) goto 1
>> 
>> The USB commands which are executed inside the newstate callback usually take
>> very little time, but still not as little time as PCI read/writes. I've forced
>> slower operation in the newstate callback, and can reproduce warning printouts
>> from the IEEE802.11 layer in FreeBSD. Try to apply the following patch to your
>> USB code:
>> 
>> http://p4web.freebsd.org/_at__at_180604?ac=10
>> 
>> In my opinion the deferring of all states to a single task is wrong. There
>> should be at least one task per possible state, and the queuing mechanism
>> should follow the last-queued is last executed rule. This is not the case with
>> the task-queue mechanism in the kernel.
> 
> This turned out to be refcounting of the ieee80211_node struct which
> was causing this panic. vap->iv_bss can be freed at any time so all
> users of it need to bump the refcount to use it safely.
> 
> This patch should fix the panic in the rum driver.
> http://people.freebsd.org/~thompsa/rum_node_refcnt.diff
> 
> There are other places where it is still an issue such as the
> ieee80211_tx_mgt_timeout callout which havnt been addressed yet, and
> of course all other ieee80211 drivers.

Oh, this makes sense now. My previous attempt at help you made no sense...

Regards,
--
Rui Paulo
Received on Mon Jul 12 2010 - 14:56:36 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:05 UTC