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(¤t->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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
