Re: [RFC PATCH(experimental) 2/2] Fix freezer-kthread_stop race

Oleg Nesterov
2007-04-20T21:12:40Z

On 04/19, Gautham R Shenoy wrote:
>
> @@ -63,12 +74,16 @@ void refrigerator(void)
> recalc_sigpending(); /* We sent fake signal, clean it up */
> spin_unlock_irq(&current->sighand->siglock);
>
> + task_lock(current);
> for (;;) {
> set_current_state(TASK_UNINTERRUPTIBLE);
> if (!frozen(current))
> break;
> + task_unlock(current);
> schedule();
> + task_lock(current);
> }
> + task_unlock(current);
> pr_debug("%s left refrigerator\n", current->comm);
> current->state = save;

Just curious, why this change?

> +int hold_freezer_for_task(struct task_struct *p)
> +{
> + int ret = 0;
> + spin_lock(&freezer_status.lock);
> + if (freezer_status.count >= 0)
> + {
> + set_tsk_thread_flag(p, TIF_FREEZER_HELD);
> + thaw_process(p);
> + freezer_status.count++;
> + ret = 1;
> + }
> + spin_unlock(&freezer_status.lock);
> +
> + return ret;
> +}

I think this can work if it is used only in kthread_stop(). But what if
another task wants to do hold_freezer_for_task(p) ? freezer_status.count
is recursive, but TIF_FREEZER_HELD is not. IOW, I believe this is not
generic enough.

Also, you are planning to add different freezing states (FE_HOTPLUG_CPU,
FE_SUSPEND, etc). In that case each of them needs a separate .count, because
it should be negative when try_to_freeze_tasks() returns. Now consider
the case when we are doing freeze_processes(FE_A | FE_B) ...

Oleg.