]> git.baikalelectronics.ru Git - kernel.git/commit
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)
commit925e5496f861d952797d5147175c8fd466bcb340
tree6cefdfef300d3431f2b2b32ec86000b0132bd762
parentb8f1ad51755d1f12cc19da892902e7e38b2662a1
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