Date: Sat, 28 Jul 2012 19:25:46 -0700 From: Adrian Chadd <adrian.chadd@gmail.com> To: Kim Culhan <w8hdkim@gmail.com> Cc: freebsd-wireless@freebsd.org Subject: Re: ath lor Message-ID: <CAJ-Vmo=GctRSXwy4R7Zt-1a0dS7WhL4K_urAfhyQDF41uxBptA@mail.gmail.com> In-Reply-To: <CAJ-VmomEvn9MPu-j8TBc9dtUzVyXtpcN-p45ZuHTR8xTDfGJ9Q@mail.gmail.com> References: <CAKZxVQUcuk=Bw0rBkOLmy1ie%2BZYqn5uNkEndW_sEOH5u-Ef04w@mail.gmail.com> <CAJ-VmomuBC0CFTkDRh8gRVAb080rc8upTif4KDAkeiG5imcoqw@mail.gmail.com> <CAJ-Vmo=ynY_kFxa4id2wu3h5C1OSarOzVJ32G3avFDWHg1dybQ@mail.gmail.com> <CAJ-VmomEvn9MPu-j8TBc9dtUzVyXtpcN-p45ZuHTR8xTDfGJ9Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi everyone, I'd really appreciate some help with this LOR. Specifically, at least explicitly mapping out the different entry points into these two locks that can/do cause issues, so we can see whether the LOR can be worked around by ensuring the problematic locking doesn't occur in parallel. I don't have the time to do all of the net80211 locking fixes that are required _and_ port new Atheros 802.11n support _and_ implement hostap power save / filtered frames support _and_ fix up the aggregation session hangs that people see. I really, really could do with some help here. I'll provide free, cool wifi hardware to anyone who tackles and fixes any of the above issues. :-) Thanks, Adrian On 27 July 2012 12:33, Adrian Chadd <adrian.chadd@gmail.com> wrote: > .. hm, so. This is quite annoying, really. > > ieee80211_iterate_nodes() is called from hostap_newstate() to do a > bunch of things, including: > > * calling sta_diassoc() on each STA; > * handling CSA for each STA (for DFS channel change) via sta_csa(); > * dropping stations when doing a CSA (via sta_drop()); > > Now, at this point the _newstate() routine has the comlock > (IEEE80211_LOCK()) held. > > So, any function that is passed to ieee80211_iterate_nodes() that also > tries to grab the comlock is going to silently fail. > > It may _be_ that the only sensible thing to do here is to force the > comlock is held before calling ieee80211_iterate_nodes(), and then > update all the functions that it calls to require the comlock be held. > > So, that'd currently be (in net80211, ignoring what are in drivers atm): > > * sta_leave() > * load_ucastkey() > * sta_disassoc() > * sta_csa() > * sta_drop() > * get_sta_space() > * get_sta_info() > * domlme() > * mesh_vdetach_peers() > * mesh_checkid() > * get_adhoc_rssi() > * get_hostap_rssi() > * get_mesh_rssi() > > .. and that's kind of scary, because a lot of those will call into the > driver and do things like transmit frames; and we absolutely can't > hold the comlock when doing that or all kinds of bad LORs will occur. > > Fixing this is going to take a little more time/patience. I'm open to > other ideas/suggestions on this. > > > > Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=GctRSXwy4R7Zt-1a0dS7WhL4K_urAfhyQDF41uxBptA>