On Wed, Dec 23, 2009 at 10:33:51AM -0800, Luis Rodriguez wrote: > The issues are as follows: > > 1) We stop TX and flush all packets out, and then call the driver stop(). > Unfortunately there is a failed assumption that even ieee80211_xmit() > would not be called after stopping TX as __ieee80211_suspend() does > above. > 2) Since ieee80211_xmit() is being called even after the driver stop() > callback it means mac80211 can potentially schedule work. Now the > new rework on the mac80211 workqueue pushes us to WARN when either > a driver or mac80211 tried to queue work onto the mac80211 workqueue > and we're suspended. A new patch from Johannes futher enhances this > to take into consideration resume so that we can allow drivers / mac80211 > to queue work if we were suspended but now resuming. Even with these > checks in place I note that currently we do slip work through after > the driver stop() callback is called and before loacl->suspended is > set to true. So there seems to be a race here. > > The first issue is not so clear to resolve as although we likely do prevent > the networking core from calling ieee80211_subif_start_xmit() it doesn't > mean ieee80211_xmit() internally will not be called by other parts of > mac80211 and indeed I do believe this is what is happening. I'll try > pin point the exact spot where this happens though, but I'll note though > that checking for local->suspended will *not* work since we already know > some work is being queued *and running!* and it wouldn't have if > local->suspended was true already. OK, not bad and pretty obvious too -- the issue is __ieee80211_suspend() will tear down BA sessions and this does require xmit'ing. The only issue then becomes that of trying to queue work after a driver stop(), that can be fixed easily and will send a patch next. 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
