Re: ath5k/mac80211: Reproducible deadlock with 64-stations.

[Ben Greear <greearb@candelatech.com>]

On 11/12/2010 02:15 AM, Tejun Heo wrote:
> Just a bit of addition.
>
> On 11/12/2010 11:11 AM, Tejun Heo wrote:
>> It depends on what the work being flushed was doing.  Which one is it
>> trying to flush?  Also, if the memory pressure is high enough, due to
>> the dynamic nature of workqueue, processing of works can be delayed
>> while trying to create new workers to process them.
>
> Please note that under those circumstances, what's guaranteed is
> forward-progress for workqueues which are used during memory reclaim.
> Continuously scheduling works which will in turn pile up on rtnl_lock
> is akin to constantly allocating memory while something holding
> rtnl_lock is blocked due to memory pressure.  Correctness-wise, it
> isn't necessarily deadlock but the only possible recourse is OOM.

 From looking at the wireless code, since sdata is stopped, the
'work' isn't going to actually do anything anyway.

Is there a way to clear the work from the work-queue w/out
requiring any locks that a running worker thread might hold?
(So instead of flush_work, we could call something like "remove_all_work"
and not block on the worker thread that may currently be trying to
acquire rtnl?)

Thanks,
Ben

>
> Thanks.
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com