[patch -mm] oom: fix constraint deadlock
From: David Rientjes
Date: Fri Apr 27 2007 - 02:21:03 EST
Fixes a deadlock in the OOM killer for allocations that are not
__GFP_HARDWALL.
Before the OOM killer checks for the allocation constraint, it takes
callback_mutex.
constrained_alloc() iterates through each zone in the allocation zonelist
and calls cpuset_zone_allowed_softwall() to determine whether an
allocation for gfp_mask is possible. If a zone's node is not in the
OOM-triggering task's mems_allowed, it is not exiting, and we did not
fail on a __GFP_HARDWALL allocation, cpuset_zone_allowed_softwall()
attempts to take callback_mutex to check the nearest exclusive ancestor
of current's cpuset. This results in deadlock.
We now take callback_mutex after iterating through the zonelist since we
don't need it yet.
Cc: Andi Kleen <ak@xxxxxxx>
Cc: Nick Piggin <npiggin@xxxxxxx>
Cc: Christoph Lameter <clameter@xxxxxxxxxxxx>
Cc: Martin J. Bligh <mbligh@xxxxxxxxxx>
Signed-off-by: David Rientjes <rientjes@xxxxxxxxxx>
---
mm/oom_kill.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -397,6 +397,7 @@ void out_of_memory(struct zonelist *zonelist, gfp_t gfp_mask, int order)
struct task_struct *p;
unsigned long points = 0;
unsigned long freed = 0;
+ int constraint;
blocking_notifier_call_chain(&oom_notify_list, 0, &freed);
if (freed > 0)
@@ -411,14 +412,15 @@ void out_of_memory(struct zonelist *zonelist, gfp_t gfp_mask, int order)
show_mem();
}
- cpuset_lock();
- read_lock(&tasklist_lock);
-
/*
* Check if there were limitations on the allocation (only relevant for
* NUMA) that may require different handling.
*/
- switch (constrained_alloc(zonelist, gfp_mask)) {
+ constraint = constrained_alloc(zonelist, gfp_mask);
+ cpuset_lock();
+ read_lock(&tasklist_lock);
+
+ switch (constraint) {
case CONSTRAINT_MEMORY_POLICY:
oom_kill_process(current, points,
"No available memory (MPOL_BIND)");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/