On Thu, 2012-12-13 at 19:24 +0100, 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. In fact, this is already buggy now, and I should probably revert b22cfcfca, because the work item might run after the AP is stopped and then we call into the driver anyway, and on teardown things are probably messed up. I'll poke at it tomorrow. 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
