Pavel Machek <pavel@ucw.cz> writes:
> > @@ -214,9 +218,12 @@
> > read_lock(&tasklist_lock);
> > do_each_thread(g, p) {
> > unsigned long flags;
> > - INTERESTING(p);
> > + if (!interesting_process(p))
> > + continue;
> > if (p->flags & PF_FROZEN)
> > continue;
> > + if (p->state == TASK_STOPPED)
> > + continue;
> >
> > /* FIXME: smp problem here: we may not access other process' flags
> > without locking */
>
> No need to handle TASK_STOPPED tasks, as they are "frozen" already. Ok.
If the process was stopped before swsusp was invoked, the process will
never reach refrigerator() and therefore never set the PF_FROZEN
flag. Without the test for TASK_STOPPED, swsusp gives up and claims
that it can't stop all processes.
> > read_lock(&tasklist_lock);
> > do_each_thread(g, p) {
> > - INTERESTING(p);
> > -
> > - if (p->flags & PF_FROZEN) p->flags &= ~PF_FROZEN;
> > - else
> > - printk(KERN_INFO " Strange, %s not stopped\n", p->comm );
> > - wake_up_process(p);
> > + if (!interesting_process(p))
> > + continue;
> > +
> > + p->flags &= ~PF_FREEZE;
> > + if (p->flags & PF_FROZEN) {
> > + p->flags &= ~PF_FROZEN;
> > + wake_up_process(p);
> > + } else
> > +
> But why do you touch PF_FROZEN here? Refrigerator should do that.
> And wake_up_process should not be needed...
> If it is in refrigerator, it polls PF_FREEZE...
Note that the old code always called wake_up_process(), which is
necessary to make the process run one more iteration in refrigerator()
and relize that it is time to unfreeze.
The patch changes things so that wake_up_process() is NOT called if
the process is stopped at some other place than in refrigerator().
This ensures that processes that were stopped before we invoked swsusp
are still stopped after resume.
I manually clear PF_FREEZE here in an attempt to handle a race
condition, but I realize I need to understand more of the scheduler
and signal code before I know for sure if this is necessary and/or
sufficient.
-- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340 - 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/
This archive was generated by hypermail 2b29 : Wed Jul 23 2003 - 22:00:43 EST