On Thu, 2012-12-13 at 10:30 -0800, Ben Greear wrote: > On 12/13/2012 10:24 AM, Johannes Berg wrote: > > On Thu, 2012-12-13 at 10:19 -0800, Ben Greear wrote: > > > >>> I don't think that's easy, but you're welcome to try. The > >>> free_sta_work() function references the sdata so it absolutely must run > >>> at this point. > > > >> So, cancel_work_sync(&sdata->work) would appear to remove > >> all pending sdata->work items from the work-queue. As long as > >> there are no other different work items that reference > >> sdata (and maybe there are..I haven't looked at all of them), > >> then we should be safe to execute the free_sta_work() > >> on a different work-queue safely, I think.... > > > > Sorry, I don't get it. free_sta_work() *itself* has to be executed > > before the sdata is destroyed. cancel_work_sync(&sdata->work) has > > nothing to do with free_sta_work. > > My concern is this: > > If I add a different work queue (called destructor-workqueue, perhaps) > for free_sta_work(), then it only helps > if I can not block on flushing the current 'big' work-queue. But, if > there are items on the big work-queue that reference sdata, then > that could easily execute after free_sta_work(), and I'm guessing > that would be very bad. > > 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? 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
