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

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.

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>`


Andrew