Another scan + comlock LOR

[Adrian Chadd]

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.
 */
static void
scan_curchan(struct ieee80211_scan_state *ss, unsigned long maxdwell)
{
        struct ieee80211vap *vap  = ss->ss_vap;

        IEEE80211_LOCK(vap->iv_ic);
        if (ss->ss_flags & IEEE80211_SCAN_ACTIVE)
                ieee80211_probe_curchan(vap, 0);
        callout_reset(&SCAN_PRIVATE(ss)->ss_scan_timer,
            maxdwell, scan_signal, ss);
        IEEE80211_UNLOCK(vap->iv_ic);
}

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?

Thanks,


Adrian