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?
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
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
