Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Jul 2010 12:07:55 +1200
From:      Andrew Thompson <thompsa@FreeBSD.org>
To:        Hans Petter Selasky <hselasky@c2i.net>
Cc:        Sam Leffler <sam@freebsd.org>, PseudoCylon <moonlightakkiy@yahoo.ca>, freebsd-usb@freebsd.org, freebsd-current@freebsd.org
Subject:   Re: [panic] Race in IEEE802.11 layer towards device drivers
Message-ID:  <AANLkTim-2GbC0fOKnZkyV_c_LzIy2hPdeC_jnNaBFXza@mail.gmail.com>
In-Reply-To: <201007072113.16320.hselasky@c2i.net>
References:  <201007072113.16320.hselasky@c2i.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 8 July 2010 07:13, Hans Petter Selasky <hselasky@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/@@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.


Andrew



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTim-2GbC0fOKnZkyV_c_LzIy2hPdeC_jnNaBFXza>