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.