K 10
svn:author
V 6
adrian
K 8
svn:date
V 27
2011-10-19T08:39:44.820196Z
K 7
svn:log
V 998
Rollback r226399 to r226516.

It turns out that no, I can't hold these locks for this long without
causing all kinds of LORs with both net80211 and the IP stack.
Things work ok in hostap mode when bridging occurs but it all utterly
fails (and very quickly) when passing IP traffic.

I'll re-merge in some of the useful work here, but I unfortunately
can't just cheat and hold locks as a method of enforcing atomic
and predictable states within the driver.

As a node: iwn holds the IWN_LOCK for long periods but it doesn't
hold it over some net80211 calls and the RX path. The TX path
however has it being held.

So when RX'ing, the net80211 ic comlock will be grabbed when
calling ieee80211_input and ieee80211_free_node().

When TX'ing, the IWN_LOCK is grabbed, then net80211 comlock will
be grabbed on completion of each frame.

So a LOR will likely occur if the IWN_LOCK is grabbed at any point
whilst the net80211 lock is held. eg, maybe a channel change? or
reset? I'll have to look into it.

END