All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srivatsa Vaddagiri <vatsa@in.ibm.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>, Ingo Molnar <mingo@elte.hu>
Cc: suresh.b.siddha@intel.com, pj@sgi.com, hawkes@sgi.com,
	linux-kernel@vger.kernel.org,
	Dinakar Guniguntala <dino@in.ibm.com>,
	Andrew Morton <akpm@osdl.org>
Subject: [PATCH 2.6.16-mm1 1/2] sched_domain: handle kmalloc failure
Date: Sat, 25 Mar 2006 13:57:30 +0530	[thread overview]
Message-ID: <20060325082730.GA17011@in.ibm.com> (raw)

I think there is a bug in build_sched_domains() when kmalloc fails to
allocate memory for 'sched_group_allnodes'. 

Consider the case where build_sched_domains() is being invoked because a
CPUset is being made exclusive. Further lets say user changed cpu_exclusive 
property of some CPUset as follow:

	echo 1 > cpu_exclusive	# (Step a)
	echo 0 > cpu_exclusive	# (Step b)
	echo 1 > cpu_exclusive	# (Step c)


Lets say that all memory allocations succeeded during the 1st attempt to
make CPUset exclusive (Step a). Step a would result in the sched domain
heirarchy being initialized for all CPUs in the CPUSet under
consideration. Step b would cause those memory allocations to be freed
up.

Now during Step c, lets say that kmalloc failed to allocate for
'sched_group_allnodes'. When that happens, the code just breaks out of
the 'for' loop. I think that is wrong, as it would cause the previous
assignments (made during Step a) to be retained. This could cause, among
other things, sd->groups to be invalid (for allnodes_domains)?

Patch below (against 2.6.16-mm1) fixes it. I have done some minimal test
of it.

Signed-off-by: Srivatsa Vaddagiri <vatsa@in.ibm.com>



 kernel/sched.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff -puN kernel/sched.c~sd_handle_error kernel/sched.c
--- linux-2.6.16-mm1/kernel/sched.c~sd_handle_error	2006-03-25 11:39:07.000000000 +0530
+++ linux-2.6.16-mm1-root/kernel/sched.c	2006-03-25 11:39:59.000000000 +0530
@@ -5965,6 +5965,7 @@ void build_sched_domains(const cpumask_t
 {
 	int i;
 #ifdef CONFIG_NUMA
+	int alloc_failed = 0;
 	struct sched_group **sched_group_nodes = NULL;
 	struct sched_group *sched_group_allnodes = NULL;
 
@@ -5993,7 +5994,7 @@ void build_sched_domains(const cpumask_t
 #ifdef CONFIG_NUMA
 		if (cpus_weight(*cpu_map)
 				> SD_NODES_PER_DOMAIN*cpus_weight(nodemask)) {
-			if (!sched_group_allnodes) {
+			if (!sched_group_allnodes && !alloc_failed) {
 				sched_group_allnodes
 					= kmalloc(sizeof(struct sched_group)
 							* MAX_NUMNODES,
@@ -6001,7 +6002,7 @@ void build_sched_domains(const cpumask_t
 				if (!sched_group_allnodes) {
 					printk(KERN_WARNING
 					"Can not alloc allnodes sched group\n");
-					break;
+					alloc_failed = 1;
 				}
 				sched_group_allnodes_bycpu[i]
 						= sched_group_allnodes;
@@ -6010,7 +6011,10 @@ void build_sched_domains(const cpumask_t
 			*sd = SD_ALLNODES_INIT;
 			sd->span = *cpu_map;
 			group = cpu_to_allnodes_group(i);
-			sd->groups = &sched_group_allnodes[group];
+			sd->groups = sched_group_allnodes ?
+				 &sched_group_allnodes[group] : NULL;
+			if (!sd->groups)
+				sd->flags = 0;		/* No load balancing */
 			p = sd;
 		} else
 			p = NULL;

_

-- 
Regards,
vatsa

             reply	other threads:[~2006-03-25  8:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-25  8:27 Srivatsa Vaddagiri [this message]
2006-03-26  2:06 ` [PATCH 2.6.16-mm1 1/2] sched_domain: handle kmalloc failure Andrew Morton
2006-03-26  2:40   ` Srivatsa Vaddagiri
2006-03-26  2:44     ` Andrew Morton
2006-03-26  3:03       ` Nick Piggin
2006-03-26  3:38         ` Srivatsa Vaddagiri
2006-03-26  4:10           ` Paul Jackson
2006-03-26  3:32       ` Srivatsa Vaddagiri

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060325082730.GA17011@in.ibm.com \
    --to=vatsa@in.ibm.com \
    --cc=akpm@osdl.org \
    --cc=dino@in.ibm.com \
    --cc=hawkes@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=pj@sgi.com \
    --cc=suresh.b.siddha@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.