On 11/14/2012 09:28 AM, Johannes Berg wrote:
On Wed, 2012-11-14 at 09:13 -0800, Ben Greear wrote:
I'm guessing that the other interfaces are actually re-scheduling work
items while this is trying to flush ... I'm not really sure how to
improve this behaviour though.
That seems very likely, as other stations would be trying to associate
in this scenario....
Can we just purge all of this interface's work items from the list w/out flushing
everyone else's work?
Actually, what I said doesn't quite make sense. We evidently use
flush_work() which doesn't care about *new* items, so I suppose it just
has to wait so long because there are other items already that are
taking a long time.
However, it seems that doing flush_work() is completely pointless,
cancel_work_sync() would be just as effective -- the work exits right
away if the interface is no longer marked running, and it is marked
not-running before we even do the flush_work(). So using
cancel_work_sync() should be safe here and would avoid the long delay
you're seeing.
Could you try this? The flush_work() is in iface.c:ieee80211_do_stop()
I just tested this in 3.7.0-rc8+ on a 400 station machine, and it
seems to work fine. I did not
see any cases where my app blocked for any abnormal amounts of time, and
doing things like 'ip link show' on the cmd line worked fine.
So, I think that's a good fix to roll upstream.
I'll continue running it my 3.7 tree, and will let you know if
I see anything funny.
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
