On 09/29, Michal Hocko wrote:
>
> On Thu 29-09-11 14:05:17, Oleg Nesterov wrote:
>
> > But of course this can't help if freeze_task() is called later.
> > May be freezable() should check TIF_MEMDIE...
>
> Wouldn't it be easier to ignore try_to_freeze when fatal signals are
> pending in get_signal_to_deliver?
Oh, I don't think so. For what? This doesn't close other races, and
in fact the fatal_signal_pending() this patch adds is itself racy,
SIGKILL can come in between.
> --- a/kernel/freezer.c
> +++ b/kernel/freezer.c
> @@ -48,6 +48,11 @@ void refrigerator(void)
> current->flags |= PF_FREEZING;
>
> for (;;) {
> + if (fatal_signal_pending(current)) {
> + if (freezing(current) || frozen(current))
> + thaw_process(current);
Ah, I didn't mean refrigerator() should check freezing/frozen.
I meant, oom_kill can do this before thaw thaw_process(), afaics
this should fix the particular race you described (but not others).
And. It is simply wrong to return from refrigerator() after we set
PF_FROZEN, this can fool try_to_freeze_tasks(). Sure, thaw_process()
from oom_kill is not nice too, but at least this is the special case,
we already have the problem.
Oleg.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>