Another scan + comlock LOR
adrian at freebsd.org
Fri Oct 21 06:53:12 UTC 2011
Hm, replying to my own email: is this lock needed to be held across
the call to ieee80211_probe_curchan() ?
* Scan curchan. If this is an active scan and the channel
* is not marked passive then send probe request frame(s).
* Arrange for the channel change after maxdwell ticks.
scan_curchan(struct ieee80211_scan_state *ss, unsigned long maxdwell)
struct ieee80211vap *vap = ss->ss_vap;
if (ss->ss_flags & IEEE80211_SCAN_ACTIVE)
maxdwell, scan_signal, ss);
ieee80211_probe_curchan() is called from a few other contexts (when
rx'ing mgmt frames) which isn't locked.
I don't like how some of these flags are checked and modified without
the comlock being held, but I also can't help but think that any form
of packet TX from net80211 to the driver which holds the comlock is
going to result in a LOR.
Eg, is it valid to walk ss->ss_ssid[i] (the list of ssids in the
current scan state) without holding a lock?
How is consistency guaranteed there?
More information about the freebsd-wireless