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

[Tejun Heo <tj@kernel.org>]

Hello,

On 11/12/2010 07:06 PM, Ben Greear wrote:
> On 11/12/2010 02:15 AM, Tejun Heo wrote:
>> 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?)

Hmmm... there's cancel_work_sync().  It'll cancel if the work is
pending and wait for completion if it's already running.  BTW, which
part of code are we talking about?  Can you please attach full thread
dump at deadlock?

Thanks.

-- 
tejun