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

Andrew Thompson thompsa at FreeBSD.org
Thu Jul 8 03:12:43 UTC 2010

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/@@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.

You dont say why it should be this way, do you have an example of a
problem this fixes?

I think the single state thread is correct. The whole thing works on
state transitions, you dont just set a state.

> Description of panics. I didn't have core dump enabled on this box, so please
> bear over with the following hand-written notes:
> 1) A vap->iv_bss == NULL, inside ratectl task in RUM driver.
> 2) A memcpy() fails inside the iee80211...newstate_cb()
> 3) This and similar printouts are seen:
> wlan0: ieee80211_new_state_locked: pending AUTH -> ASSOC transition lost

Can you see if you can get a core dump, or at least a DDB trace and
the output from `show vap <addr>`


More information about the freebsd-current mailing list