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

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. See the USB code's task-queue 
replacement which I think the IEEE802.11 stack in FreeBSD could take advantage 
of.

src/sys/dev/usb/usb_process.c

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


--HPS