linux-kernel - Re: Regression in 2.6.23-rc2-mm2, mounting cpusets causes a hang

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 14 Aug 2007 17:37:12 -0400
From:	Lee Schermerhorn <Lee.Schermerhorn@...com>
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	Dhaval Giani <dhaval@...ux.vnet.ibm.com>, clameter@....com,
	bob.picco@...com, nacc@...ibm.com, kamezawa.hiroyu@...fujitsu.com,
	mel@...net.ie, akpm@...ux-foundation.org,
	Balbir Singh <balbir@...ibm.com>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	lkml <linux-kernel@...r.kernel.org>,
	ckrm-tech <ckrm-tech@...ts.sourceforge.net>
Subject: Re: Regression in 2.6.23-rc2-mm2, mounting cpusets causes a hang

On Tue, 2007-08-14 at 15:49 -0500, Serge E. Hallyn wrote:
<snip>
> 
> Here is a patch which fixes the bug on my system.  As noted in
> the patch description, there are other calls to node_set_state() in
> mm/page_alloc.c which might also need to be switched to node_set(),
> if this is deemed the right solution.

Here's an update to that patch to handle the other 2 places I found
where node_set_state() would be a no-op when MAX_NUMNODES == 1.

I'm continuing to look at uses of node_online_map throughout the kernel.
I'll look at current usage of the node state wrappers as well.  However,
you probably want to fix these other 2 places as well, or you might run
into other issues with empty 'NORMAL_MEMORY and 'CPU node state masks...

Lee

[PATCH 1/1] memoryless: actually set node_states[N_HIGH_MEMORY] - v2

v1 -> v2"
+  switch to node_set() to initialize N_NORMAL_MEMORY and N_CPU
   node_states[] as well.

If CONFIG_NODES_SHIFT is unset, then MAX_NUMNODES=1, and
node_set_state() does nothing.  This means that __build_all_zonelists()
does not actually set node_states[N_HIGH_MEMORY].  cpusets needs
 node_states[N_HIGH_MEMORY] to be correctly set, or it will raise a
bug when a new cpuset is created.

Switch to using node_set() in __build_all_zonelists() to
make sure it is actually set.

Note there are other calls to node_set_state() in mm/page_alloc.c,
which perhaps should also be modified.  Since this area is completely
foreign to me I thought I'd first make sure this is the right approach.

	addressed in v2 --lts

Signed-off-by: Serge E. Hallyn <serue@...ibm.com>
Signed-off-by: Dhaval Giani <dhaval@...ux.vnet.ibm.com>
Signed-off-by: Lee Schermerhorn <lee.schermerhorn@...com>

 mm/page_alloc.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

Index: Linux/mm/page_alloc.c
===================================================================
--- Linux.orig/mm/page_alloc.c	2007-08-14 16:48:28.000000000 -0400
+++ Linux/mm/page_alloc.c	2007-08-14 16:57:24.000000000 -0400
@@ -2425,7 +2425,8 @@ static void check_for_regular_memory(pg_
 	for (zone_type = 0; zone_type <= ZONE_NORMAL; zone_type++) {
 		struct zone *zone = &pgdat->node_zones[zone_type];
 		if (zone->present_pages)
-			node_set_state(zone_to_nid(zone), N_NORMAL_MEMORY);
+			node_set(zone_to_nid(zone),
+					node_states[N_NORMAL_MEMORY]);
 	}
 #endif
 }
@@ -2443,7 +2444,7 @@ static int __build_all_zonelists(void *d

 		/* Any memory on that node */
 		if (pgdat->node_present_pages)
-			node_set_state(nid, N_HIGH_MEMORY);
+			node_set(nid, node_states[N_HIGH_MEMORY]);
 		check_for_regular_memory(pgdat);
 	}
 	return 0;
@@ -2793,7 +2794,7 @@ static int __cpuinit process_zones(int c
 			 	(zone->present_pages / percpu_pagelist_fraction));
 	}

-	node_set_state(node, N_CPU);
+	node_set(node, node_states[N_CPU]);
 	return 0;
 bad:
 	for_each_zone(dzone) {

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/