On Wed, 2012-11-14 at 09:13 -0800, Ben Greear wrote: > > I'm guessing that the other interfaces are actually re-scheduling work > > items while this is trying to flush ... I'm not really sure how to > > improve this behaviour though. > > That seems very likely, as other stations would be trying to associate > in this scenario.... > > Can we just purge all of this interface's work items from the list w/out flushing > everyone else's work? Actually, what I said doesn't quite make sense. We evidently use flush_work() which doesn't care about *new* items, so I suppose it just has to wait so long because there are other items already that are taking a long time. However, it seems that doing flush_work() is completely pointless, cancel_work_sync() would be just as effective -- the work exits right away if the interface is no longer marked running, and it is marked not-running before we even do the flush_work(). So using cancel_work_sync() should be safe here and would avoid the long delay you're seeing. Could you try this? The flush_work() is in iface.c:ieee80211_do_stop() johannes -- 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
