Date: Fri, 21 Oct 2011 14:53:11 +0800 From: Adrian Chadd <adrian@freebsd.org> To: Bernhard Schmidt <bschmidt@freebsd.org> Cc: freebsd-wireless@freebsd.org Subject: Re: Another scan + comlock LOR Message-ID: <CAJ-Vmo=a0uBcxJ-Thk1A230ZFfohCyn7VuLHxPexcy-YwBCcAA@mail.gmail.com> In-Reply-To: <CAJ-Vmo=UwuwE31ww5neWDK2GWfbRyX1E_LAbfjw_Rmb3g_VRhQ@mail.gmail.com> References: <CAJ-Vmo=UwuwE31ww5neWDK2GWfbRyX1E_LAbfjw_Rmb3g_VRhQ@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=a0uBcxJ-Thk1A230ZFfohCyn7VuLHxPexcy-YwBCcAA>