K 10
svn:author
V 6
adrian
K 8
svn:date
V 27
2011-08-17T23:59:55.229400Z
K 7
svn:log
V 1709
Close up any BAW races as much as possible; document the current problem
and the workaround.

In the first cut of this code, packet scheduling (ie, stuffing into a
software or hardware TXQ) occured in the same context as the serialised
TX from the net80211/netif code. When addba was set, the TID could
be paused, and anything queued into the software queue would sit there
and wait. Once the TID was unpaused, all those queued packets with
sequence numbers would fall into an aggregate TID, and their sequence
numbers would happily fall into the BAW.

Now, packet scheduling occurs in the task context rather than the TX
context. So when the TID is paused, any currently running packet
scheduler/queue function in the ath task may be running concurrently.
So it's possible that some packets would be dumped to the hardware
before the TID pause value was checked.

This commit (mostly) fixes the races in checking the TID paused flag.
It doesn't check for races when forming aggregates; I'll worry about
that later when I'm actively making aggregate frames. But as the
TID isn't being locked for the entire duration of the packet scheduling
and hardware queue, it's quite possible one will leak by between when
TID->paused is set, and the next time it's checked.

I'm also "sliding" the left edge of the BAW along to match whatever
sequence numbers net80211 assigns between addba being setup and
addba being actually enabled. The (likely) correct way to handle this
is to queue frames during addba setup for this TID as aggregates without
creating sequence numbers for them. If the TID pause is handled correctly,
this should occur.

This needs to be revisited and fixed before the code is merged into
-HEAD.

END