On Tue, Apr 03, 2007 at 03:47:29PM +0400, Oleg Nesterov wrote:
cleanup_workqueue_thread (in Gautham's patches) does this:
thaw_process()
kthread_stop()
There is a chance that after thaw_process() [but before we have posted
the kthread_stop], worker thread can come out of the refrigerator and start
running run_workqueue() - that will simply prolong the subsequent
kthread_stop() and the system freeze time.
We could do what you are suggesting if the thaw_process() part was
integrated into kthread_stop() code [basically thaw_process after
setting the kthread_stop_info.k flag].
Why?
I tend to agree yes.
[snip]
Good catch! Can cleanup_workqueue_thread take some mutex to serialize
with freezer here (say freezer_mutex)?
Or better, since this seems to be a general problem for anyone who wants to do a
kthread_stop, how abt modifying kthread_stop like below:
kthread_stop(p)
{
int old_exempt_flags;
task_lock(p);
old_exempt_flags = p->flags;
p->flags |= PFE_ALL; /* Exempt 'p' from being frozen? */
task_unlock(p);
kthread_stop_info.k = p;
thaw_process(p);
wait_for_completion();
}
Marking 'p' as exempt shouldn't be a problem because freezer would wait
on the thread doing kthread_stop() anyway before declaring system as
frozen.
yeah ..
The workqueue_mutex() should serialize these with workqueue_cpu_callback() to
an extent, but ..
Yes I agree, we should target freezing everybody here. It feels much
safer that way!
The only dependency I have seen is stop_machine() called after processes
are frozen. It needs the services of a workqueue to create kthreads. We
need to atleast exempt that worker thread from being frozen. Hopefully
the list of such non-freezable singlethreaded workqueues will be tiny
enough for us to audit time-to-time.
Ok you seem to have covered what I went out to say above!
Thx for your review so far ..
--
Regards,
vatsa
-