freezer vs stopped or traced
authorRoland McGrath <roland@redhat.com>
Tue, 4 Mar 2008 04:22:05 +0000 (20:22 -0800)
committerLinus Torvalds <torvalds@woody.linux-foundation.org>
Tue, 4 Mar 2008 15:59:54 +0000 (07:59 -0800)
commit13b1c3d4b49bd83d861c775ca2db54e1692a1b07
tree6cefdfef300d3431f2b2b32ec86000b0132bd762
parent976dde010e513a9c7c3117a32b7b015f84b37430
freezer vs stopped or traced

This changes the "freezer" code used by suspend/hibernate in its treatment
of tasks in TASK_STOPPED (job control stop) and TASK_TRACED (ptrace) states.

As I understand it, the intent of the "freezer" is to hold all tasks
from doing anything significant.  For this purpose, TASK_STOPPED and
TASK_TRACED are "frozen enough".  It's possible the tasks might resume
from ptrace calls (if the tracer were unfrozen) or from signals
(including ones that could come via timer interrupts, etc).  But this
doesn't matter as long as they quickly block again while "freezing" is
in effect.  Some minor adjustments to the signal.c code make sure that
try_to_freeze() very shortly follows all wakeups from both kinds of
stop.  This lets the freezer code safely leave stopped tasks unmolested.

Changing this fixes the longstanding bug of seeing after resuming from
suspend/hibernate your shell report "[1] Stopped" and the like for all
your jobs stopped by ^Z et al, as if you had freshly fg'd and ^Z'd them.
It also removes from the freezer the arcane special case treatment for
ptrace'd tasks, which relied on intimate knowledge of ptrace internals.

Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
kernel/power/process.c
kernel/signal.c