summaryrefslogtreecommitdiffstats
path: root/arch/m68knommu/kernel/entry.S
diff options
context:
space:
mode:
authorRoland McGrath <roland@redhat.com>2008-03-03 20:22:05 -0800
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2008-03-04 07:59:54 -0800
commit13b1c3d4b49bd83d861c775ca2db54e1692a1b07 (patch)
tree6cefdfef300d3431f2b2b32ec86000b0132bd762 /arch/m68knommu/kernel/entry.S
parent976dde010e513a9c7c3117a32b7b015f84b37430 (diff)
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>
Diffstat (limited to 'arch/m68knommu/kernel/entry.S')
0 files changed, 0 insertions, 0 deletions