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@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
