Description Adrian Chadd 2012-12-09 00:50:00 UTC

There are panics in the net80211 fast-frame queue ageing and flushing code.

It looks like the staging queue ends up being empty and the net80211 FF routines have KASSERT()s to make sure the queue isn't empty.  I'm guessing its a sanity check - it shouldn't be called when the queues are empty.

However, the check is done without the comlock being held, so it's entirely plausible that there'll be a race or preemption between the check and actually checking/emptying the queue; where another thread (CPU or preempted thread) will empty the FF AC queue for us; once this returns it panics.

kgdb analysis of a crashdump shows:

* ath_tx_processq()
* ieee80211_ff_flush()
* ieee80211_ff_age()

ieee80211_ff_flush() checks if the queue is empty and if not, it calls ieee80211_ff_flush().

There's a bunch of places the FF routines are called from and these can and do overlap.

Fix: 

The solutions?

* stick the ieee80211_ff_*() calls in a specific taskqueue and call them from there, rather than from both the TX, RX and TX completion context;
* grab the comlock before checking, and make sure the function expects the comlock to be held and frees the comlock after;
* Just accept (and document) the check is racy/opportunistic; and remove the "is the queue empty?" KASSERT()s in the FF code.
How-To-Repeat: * run 9-stable or -head with assert/witness enabled;
* iperf TCP between FF capable stations - just wait a while, it'll eventually trigger!