sysctl_panic_on_oom broken

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:

@@ -431,6 +437,9 @@ void out_of_memory(struct zonelist *zone
 	cpuset_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 *zone
 		break;
 
 	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

It recreates the old problem that we OOM while we still have memory in other parts of the system.

How, by the time we get here we have already decided we are going to OOMkill or panic. This change just obeys sysctl_panic_on_oom before killing current.

-----------------------------------------------------------------------

        /* 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
         * NUMA) that may require different handling.
         */
        switch (constrained_alloc(zonelist, gfp_mask)) {
        case CONSTRAINT_MEMORY_POLICY:
                oom_kill_process(current, points,
                                "No available memory (MPOL_BIND)");
                break;

        case CONSTRAINT_CPUSET:
                oom_kill_process(current, points,
                                "No available memory in cpuset");
                break;

        case CONSTRAINT_NONE:
retry:
                /*
                 * Rambo mode: Shoot down a process and hope
                 * issues we may have.
                 */
                p = select_bad_process(&points);

                if (PTR_ERR(p) == -1UL)
                        goto out;

                /* Found nothing?!?! Either we hang or we panic. */

If you panic then there is no reason to kill current. Lets say you have a 10 node system and the application attempt to allocate from node 8 which has no reclaimable memory then the application has a problem not the system as a whole.

Hmm. User's expectation is failover of clustering ASAP by panic. Even if free memory remain due to cpuset/mempolicy setting, some people may want failover soon.

Of course some other people don't want panic if free memory remain. I think it depends on user.

If panic_on_oom is 1, only panic if mempolicy/cpuset is not used. And if panic_on_oom is 2, panic on all case.
This might be desirable.

Bye.

Yasunori Goto 

Sounds good. Add some documentation mentioned that this may panic your system if there is still plenty of memory available.