Messages in this thread | | | Date | Wed, 4 Apr 2007 23:19:48 +0530 | From | Srivatsa Vaddagiri <> | Subject | Re: [PATCH 7/8] Clean up workqueue.c with respect to the freezer based cpu-hotplug |
| |
On Wed, Apr 04, 2007 at 07:28:28PM +0400, Oleg Nesterov wrote: > I changed my mind :) The problem is general, I am starting to believe > it is better to change kthread_stop().
yes i agree. Although is some cases like destroy_workqueue, we need to mark the target thread non-freezable way before we call kthread_stop (as you pointed out).
> > I suspected that we cannot modify p->flags just like that. How abt > > moving freezer exemption bits to a separate field, which is protected by > > task_lock? > > Probably yes... In that case it makes sense to move PF_FREEZER_SKIP/PF_FROZEN > to the new field as well.
I wonder if there are some reserved fields in task_struct which we can reuse here ..
> Perhaps we can ignore this problem for now. Freezer is not 100% reliable > anyway. For example, > > worker_thread: > > for (;;) { > try_to_freeze(); > > prepare_to_wait(); > if (...) > schedule(); > finish_wait(); > } > > This is racy, we can miss freeze_process()->signal_wake_up() if it happens > between try_to_freeze() and prepare_to_wait(). We have to check TIF_FREEZE > before entering schedule() if we want to fix this race.
Yes that needs a fix as well. Oh dear, freezer is so fragile to break!
> Should we? I don't know. This will uglify the code, and the probability > of this race is very low.
Would be nice to fix IMO. Atleast serves to show "how to make your code freezer friendly".
-- 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/
| |