The patch titled
oom: don't kill current when another OOM in progress
has been added to the -mm tree. Its filename is
oom-dont-kill-current-when-another-oom-in-progress.patch
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
------------------------------------------------------
Subject: oom: don't kill current when another OOM in progress
From: Nick Piggin <npiggin@xxxxxxx>
A previous patch to allow an exiting task to OOM kill itself (and thereby
avoid a little deadlock) introduced a problem. We don't want the
PF_EXITING task, even if it is 'current', to access mem reserves if there
is already a TIF_MEMDIE process in the system sucking up reserves.
Also make the commenting a little bit clearer, and note that our current
scheme of effectively single threading the OOM killer is not itself
perfect.
Signed-off-by: Nick Piggin <npiggin@xxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
---
mm/oom_kill.c | 23 +++++++++++++++++------
1 files changed, 17 insertions(+), 6 deletions(-)
diff -puN mm/oom_kill.c~oom-dont-kill-current-when-another-oom-in-progress mm/oom_kill.c
--- a/mm/oom_kill.c~oom-dont-kill-current-when-another-oom-in-progress
+++ a/mm/oom_kill.c
@@ -217,6 +217,18 @@ static struct task_struct *select_bad_pr
continue;
/*
+ * This task already has access to memory reserves and is
+ * being killed. Don't allow any other task access to the
+ * memory reserve.
+ *
+ * Note: this may have a chance of deadlock if it gets
+ * blocked waiting for another task which itself is waiting
+ * for memory. Is there a better alternative?
+ */
+ if (test_tsk_thread_flag(p, TIF_MEMDIE))
+ return ERR_PTR(-1UL);
+
+ /*
* This is in the process of releasing memory so wait for it
* to finish before killing some other task by mistake.
*
@@ -224,16 +236,15 @@ static struct task_struct *select_bad_pr
* go ahead if it is exiting: this will simply set TIF_MEMDIE,
* which will allow it to gain access to memory reserves in
* the process of exiting and releasing its resources.
- * Otherwise we could get an OOM deadlock.
+ * Otherwise we could get an easy OOM deadlock.
*/
- if ((p->flags & PF_EXITING) && p == current) {
+ if (p->flags & PF_EXITING) {
+ if (p != current)
+ return ERR_PTR(-1UL);
+
chosen = p;
*ppoints = ULONG_MAX;
- break;
}
- if ((p->flags & PF_EXITING) ||
- test_tsk_thread_flag(p, TIF_MEMDIE))
- return ERR_PTR(-1UL);
if (p->oomkilladj == OOM_DISABLE)
continue;
_
Patches currently in -mm which might be from npiggin@xxxxxxx are
git-block.patch
mm-vm_bug_on.patch
radix-tree-rcu-lockless-readside.patch
redo-radix-tree-fixes.patch
adix-tree-rcu-lockless-readside-update.patch
adix-tree-rcu-lockless-readside-fix-2.patch
mm-remove_mapping-safeness.patch
mm-non-syncing-lock_page.patch
oom-use-unreclaimable-info.patch
oom-reclaim_mapped-on-oom.patch
oom-cpuset-hint.patch
oom-handle-current-exiting.patch
oom-handle-oom_disable-exiting.patch
oom-swapoff-tasks-tweak.patch
oom-kthread-infinite-loop-fix.patch
oom-more-printk.patch
update-some-mm-comments.patch
select_bad_process-cleanup-releasing-check.patch
oom-dont-kill-current-when-another-oom-in-progress.patch
sched-force-sbin-init-off-isolated-cpus.patch
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
