lkml.org 
[lkml]   [2007]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH(experimental) 2/2] Fix freezer-kthread_stop race
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.

-
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/

\
 
 \ /
  Last update: 2007-04-20 23:15    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site