On Thu, 2012-12-13 at 10:47 -0800, Ben Greear wrote: > On 12/13/2012 10:41 AM, Johannes Berg wrote: > > On Thu, 2012-12-13 at 10:39 -0800, Ben Greear wrote: > > > >>>> So, near where we currently call cancel_work_sync(&sdata->work), I > >>>> think we'd also need to cancel things like the sta->ampdu_mlme.work, > >>>> and probably others as well. > >>>> > >>>> Then, when we're sure there are no more references to sdata on the > >>>> main-work-queue, it would be safe to flush the destructor-workqueue > >>>> (which would have the fre_sta_work() on it). > >>>> > >>>> Maybe? > >>> > >>> Huh, ok, but I don't think you'll find much that doesn't reference an > >>> sdata? > >> > >> I think you are right...so just need to find all of those work items > >> and call cancel_work_sync() on them, just like we are currently cancelling > >> the sdata->work.... > > > > Well the concern there is that we expose the workqueue to the driver, > > and it might even put sdata-referencing work items on it and expect them > > to be flushed out before stop_interface() is called? > > > > You'd be welcome to change the API so that isn't true, or things are > > different, or whatever, but it'd be a lot of careful auditing (and > > probably fixing) of drivers. > > So, maybe a new driver api call to 'cancel_all_work_items(sdata)', > and if the driver does not implement this, then we stick with the > full flush_workqueue() in mac80211_do_stop(). But, if the driver > does implement it, and we add code there to flush any mac80211 related > work-items, then we could skip the flush_workqueue() call.... You don't even need the API, it can do it in remove_interface(). It's just not ... guaranteed right now. Also, if it wants them to run, locking may get tricky? 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
