Hi!
> > >(2) the race between the delivery of
> > > the continuation signal and the freezer is damn hard to trigger (still I think
> > > I can wirte some artificial code that would trigger this, although it would
> > > involve a kernel thread sending SIGCONT to a user space process - provided
> > > it's permissible ;-)).
> >
> > It is not really permissible, but I do not see how it would hurt...
> >
> > With that patch, we put TASK_STOPPED tasks into refrigerator, along
> > with everyone else. SIGCONT is *not* going to help them out of
> > refrigerator.
> >
> > We also ignore TASK_STOPPED now, so we'll not proceed until all
> > stopped tasks are in refrigerator.
> >
> > Now... I'm not 100% sure I got the ptrace() cases right (and did not
> > test that)... but TASK_STOPPED cases look pretty trivial to me now.
>
> Please note that currently (and with your patch) freezeable() returns 0 for
I cerainly wanted freezable to return 1 for TASK_STOPPED... and I
think this part of my patch should be doing it...?
diff --git a/kernel/power/process.c b/kernel/power/process.c
index 7bcc976..d56e494 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -26,8 +26,7 @@ static inline int freezeable(struct task
(p->flags & PF_NOFREEZE) ||
(p->exit_state == EXIT_ZOMBIE) ||
(p->exit_state == EXIT_DEAD) ||
- ((p->exit_state == TASK_TRACED) && frozen(p->parent)) ||
- (p->state == TASK_STOPPED))
+ ((p->exit_state == TASK_TRACED) && frozen(p->parent)))
return 0;
return 1;
}
> TASK_STOPPED, so we don't set PF_FREEZE for them and my patch changes
> _exactly_ that and adds some minor (optional) modifications to the error
> paths.
--
Thanks for all the (sleeping) penguins.
