sysctl_panic_on_oom broken
Subsystems (2)
out_of_memory() does not panic when sysctl_panic_on_oom is set if constrained_alloc() does not return CONSTRAINT_NONE. Instead, out_of_memory() kills the current process whenever constrained_alloc() returns either CONSTRAINT_MEMORY_POLICY or CONSTRAINT_CPUSET. This patch fixes this problem:
mm/oom_kill.c renamed from mm/oom_kill.c.orig +3 -2
@@ -431,6 +437,9 @@ void out_of_memory(struct zonelist *zonecpuset_lock ();read_lock (&tasklist_lock); +/* check if we are going to panic before enything else... */ +if (sysctl_panic_on_oom) +panic ("out of memory. panic_on_oom is selected\n" );/* * Check if there were limitations on the allocation (only relevant for * NUMA) that may require different handling.
@@ -447,8 +456,6 @@ void out_of_memory(struct zonelist *zonebreak ;case CONSTRAINT_NONE : -if (sysctl_panic_on_oom) -panic ("out of memory. panic_on_oom is selected\n" ); retry:/* * Rambo mode: Shoot down a process and hope it solves whatever
Quoted 5 lines · Larry Woodman
out_of_memory()does not panic whensysctl_panic_on_oomis set ifconstrained_alloc()does not returnCONSTRAINT_NONE. Instead,out_of_memory()kills the current process wheneverconstrained_alloc()returns eitherCONSTRAINT_MEMORY_POLICYorCONSTRAINT_CPUSET. This patch fixes this problem:
The patch recreates the problem that the system may OOM although lots of memory is still free. Constrained allocation means that the allocation was only to a portion of system memory. The rest may be free. No reason to oom.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>