Attempt to address some potential vap->iv_bss race conditions.

There are unfortunately a number of situations where vap->iv_bss is changed
or freed by some code in net80211.  Because multiple threads can concurrently
be doing work (and the vap->iv_bss access isn't at all done behind any kind
of lock), it's quite possible that:

* a change will occur in one thread - eg, by a call through
  ieee80211_sta_join1();
* a state change occurs in another thread - eg an RX is scheduled
  in the ath tasklet and it calls ieee80211_input_mimo_all(), which
  does dereference vap->iv_bss;
* these two executing concurrently, causing things to explode.

Another instance is ath_beacon_alloc() which takes an ieee80211_node *.
It's called with the vap->iv_bss node from ath_newstate(). If the node has
changed in the meantime (say it's been freed elsewhere) the reference
that it grabbed _before_ refcounting it may be stale.

I would _prefer_ that these sorts of things were serialised somewhere but
that may be a bit much to ask.  Instead, the best we can (currently) hope
is that the underlying bss node is still (somewhat) valid.

There is a related PR (kern/164382) described by the first case above.
That should be fixed by properly serialising the RX path and reset path
so an RX can't occur at the same time as the vap free/shutdown path.

This is inspired by some related fixes in r212127.

PR: kern/165060

0 files changed, 0 insertions, 0 deletions