On Thu, Oct 7, 2010 at 12:18 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 2010-10-06 at 13:48 -0700, Luis R. Rodriguez wrote: >> On Wed, Oct 6, 2010 at 12:19 PM, Johannes Berg >> <johannes@xxxxxxxxxxxxxxxx> wrote: >> > On Wed, 2010-10-06 at 12:12 -0700, Luis R. Rodriguez wrote: >> > >> >> Good question, will ieee80211_offchannel_ps_disable() possibly be >> >> called during suspend? I can imagine its possible. So how about we >> >> check for local->quiescing prior to lifting the flag only: >> > >> > Or suspended? >> >> If we're suspended we would be quiesced so I do not see us calling >> ieee80211_offchannel_ps_disable() then, but we can also just bail out >> if quescing or suspended on Âieee80211_offchannel_ps_disable() and >> friends. > > Oh, wait, yeah, while quiescing we stop the workqueue so we can't be > processing this, so we should be fine. Right. > We might still be off-channel > while suspending which is odd, and then we might lift the BA block > earlier than you'd want. Hehe.. unless we deny going off channel when quiescing or suspended. > But then again, come to think of it, why are you doing this anyway? The goal is to clean up a lot of stuff we forgot to cleanup for offchannel operation and in the end to help with multicast/broadcast data. This patch just addresses one of the cleanups. The timers kicked off when going off channel will not make sense, so best to just deny ADDBA when going offchannel. > I'm not convinced of the whole idea, it's all racy. I'm starting to think > that this patch won't help anything since we'll still be racy and start > BA agreements just before we block, Establishing the BA agreement is fine, we don't want to cancel existing BA agreements when going offchannel, we just want to prevent making the timers for new ADDBA requests from going stale unnecessarily. > _and_ if we're a station and going off-channel we'll be going into powersave > which means we won't actually get the addBA frame until we return. There's a race between trying to go offchannel, sending the nullfunc and switching channels. When the race hits the ADDBA timer will just go stale. If our goal is to go offchannel we should avoid the race by simply denying new ADDBA requests. I just noticed that we can't possible receive ADDBA requests when we are scanning though, since ieee80211_iface_work() already has a check and bail out for local->scanning, but note that local->scanning will not be checked when doing other offchannel work. So perhaps there is another way we can deal with this for the non-scanning offchannel work case that might also take care of not handling other queued up management frames when offchannel. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
