On 12/13/2012 09:59 AM, Johannes Berg wrote:
On Thu, 2012-12-13 at 09:46 -0800, Ben Greear wrote:
As previously posted, there can be cases where the RTNL is held for a
very long time when trying to do the: flush_workqueue(local->workqueue);
in mac80211_do_stop because there are lots of 'slow' work-items queued up.
I'd like to work on making this faster...
My first idea is to add a second work-queue to the 'local' for high-priority
items that can be executed independently from the current local->workqueue,
and put the free_sta_rcu work() in that queue.
I'm guessing that to be safe, the do_stop() code would need to selectively
purge any work items in the local->workqueue that relate to the sdata
being destroyed, as well. I'm not sure how possible that would be...
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.
The only/easiest thing that seems vaguely safe would be a per-vif
workqueue for this? But that's really annoying too, since it needs an
extra thread etc.
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....
I'll go look at the other work items and see what I can see.
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
