lkml.org 
[lkml]   [2009]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/3] workqueue: not allow recursion run_workqueue
On 02/05, Lai Jiangshan wrote:
>
> DEADLOCK EXAMPLE for explain my above option:
>
> (work_func0() and work_func1() are work callback, and they
> calls flush_workqueue())
>
> CPU#0 CPU#1
> run_workqueue() run_workqueue()
> work_func0() work_func1()
> flush_workqueue() flush_workqueue()
> flush_cpu_workqueue(0) .
> flush_cpu_workqueue(cpu#1) flush_cpu_workqueue(cpu#0)
> waiting work_func1() in cpu#1 waiting work_func0 in cpu#0
>
> DEADLOCK!

I am not sure. Note that when work_func0() calls run_workqueue(),
it will clear cwq->current_work, so another flush_ on CPU#1 will
not wait for work_func0, no?

But anyway. Nobody argues, "if (cwq->thread == current) {...}" code in
flush_cpu_workqueue() is bad and should die. Otrherwise, we should
fix the lockdep warning ;)

The only problem: if we still have the users of this hack, they will
deadlock. But perhaps it is time to fix them.

And, if it was not clear, I do agree with this change. And Peter
seems to agree as well.

Oleg.



\
 
 \ /
  Last update: 2009-02-05 18:07    [W:1.092 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site