Re: 'ip' blocking for long time trying to down station

[Ben Greear <greearb@candelatech.com>]

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@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com