summaryrefslogtreecommitdiff
path: root/kernel
diff options
context:
space:
mode:
authorAndrew Morton <akpm@digeo.com>2002-10-28 16:23:03 -0800
committerJens Axboe <axboe@suse.de>2002-10-28 16:23:03 -0800
commitf7844601fb857a2243575dc0efef6b6f06bd771f (patch)
treefeff74613bf2ef1a2b9bfb9caabb5dade80a3737 /kernel
parentd08b03c56de70044a7940f5aea1690b8eda2f1ae (diff)
[PATCH] thread-aware oom-killer
From Ingo - performance optimization: do not kill threads in the same thread group as the OOM-ing thread. (it's still necessery to scan over every thread though, as it's possible to have CLONE_VM threads in a different thread group - we do not want those to escape the OOM-kill.) - to not let newly created child threads slip out of the group-kill. Note that the 2.4 kernel's OOM handler has the same problem, and it could be the reason why forkbombs occasionally slip out of the OOM kill.
Diffstat (limited to 'kernel')
-rw-r--r--kernel/fork.c8
1 files changed, 8 insertions, 0 deletions
diff --git a/kernel/fork.c b/kernel/fork.c
index f8620b82f8f5..2f5f00301182 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -863,6 +863,14 @@ static struct task_struct *copy_process(unsigned long clone_flags,
/* Need tasklist lock for parent etc handling! */
write_lock_irq(&tasklist_lock);
+ /*
+ * Check for pending SIGKILL! The new thread should not be allowed
+ * to slip out of an OOM kill. (or normal SIGKILL.)
+ */
+ if (sigismember(&current->pending.signal, SIGKILL)) {
+ write_unlock_irq(&tasklist_lock);
+ goto bad_fork_cleanup_namespace;
+ }
/* CLONE_PARENT re-uses the old parent */
if (clone_flags & CLONE_PARENT)