Messages in this thread | | | Date | Thu, 4 Jan 2007 21:26:49 +0530 | From | Srivatsa Vaddagiri <> | Subject | Re: [PATCH, RFC] reimplement flush_workqueue() |
| |
On Thu, Jan 04, 2007 at 05:29:36PM +0300, Oleg Nesterov wrote: > Thanks, I need to think about this. > > However I am not sure I fully understand the problem. > > First, this deadlock was not introduced by recent changes (including "single > threaded flush_workqueue() takes workqueue_mutex too"), yes?
AFAIK this deadlock originated from Andrew's patch here:
http://lkml.org/lkml/2006/12/7/231
(Yes, your patches didnt introduce this. I was just reiterating here my earlier point that workqueue code is broken of late wrt cpu hotplug).
> Also, it seems to me we have a much more simple scenario for deadlock. > > events/0 runs run_workqueue(), work->func() sleeps or takes a preemtion. CPU 0 > dies, keventd thread migrates to another CPU. CPU_DEAD calls kthread_stop() under > workqueue_mutex and waits for until kevents thread exits. Now, if this work (or > another work pending on cwq->worklist) takes workqueue_mutex (for example, does > flush_workqueue) we have a deadlock. > > No?
Yes, the above scenario also will cause a deadlock.
I supposed one could avoid the deadlock by having a 'workqueue_mutex_held' flag and avoid taking the mutex set under some conditions, but IMHO a more neater solution is to provide a cpu-hotplug lock which works under all these corner cases. One such proposal was made here:
http://lkml.org/lkml/2006/10/26/65
-- Regards, vatsa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |