[PATCH] fix sys cpumap for > 352 NR_CPUS

[Paul Jackson]

Due to a bug in the 2.6 kernel, the cpumap files, such as:

  /sys/devices/system/node/node1/cpumap

only display the high order 352 CPUs.  If you compile a kernel with
NR_CPUS=512, such as SGI's Altix is usually compiled, then the low order
512-352 == 160 CPU positions are not shown.

This bug breaks Andi Kleens numactl and libnuma user code which depends
on this file presenting correctly.  Andi has reviewed this fix, and it
builds, boots and fixes the breakage (ia64 with sn2_defconfig).

Please apply the following patch (a hack, but better than the hack that
was there before).

Signed-off-by: Paul Jackson <pj@xxxxxxx>

===================================================================
--- 2.6.7-rc2-mm1-bitmapv6.orig/drivers/base/node.c 2004-06-02 02:04:12.000000000 -0700
+++ 2.6.7-rc2-mm1-bitmapv6/drivers/base/node.c	    2004-06-02 15:38:15.000000000 -0700
@@ -21,9 +21,21 @@ static ssize_t node_read_cpumap(struct s
 	cpumask_t mask = node_dev->cpumap;
 	int len;
 
-	/* FIXME - someone should pass us a buffer size (count) or
-	 * use seq_file or something to avoid buffer overrun risk. */
-	len = cpumask_scnprintf(buf, 99 /* XXX FIXME */, mask);
+	/*
+	 * Hack alert:
+	 * 1) This could overwrite a buffer w/o warning.  Someone should
+	 *     pass us a buffer size (count) or use seq_file or something
+	 *     to avoid buffer overrun risks.
+	 * 2) This can return a count larger than the read size requested
+	 *     by the user code - possibly confusing it.
+	 * 3) Following hardcodes that mask scnprintf format requires 9
+	 *     chars of output for each 32 bits of mask or fraction.
+	 * 4) Following prints stale node_dev->cpumap value, instead of
+	 *     evaluating afresh node_to_cpumask(node_dev->sysdev.id).
+	 * 5) Why does struct node even has the field cpumap.  Won't it
+	 *     just get stale, especially in the face of cpu hotplug?
+	 */
+	len = cpumask_scnprintf(buf, ((NR_CPUS+31)/32)*9 /* XXX FIXME */, mask);
 	len += sprintf(buf + len, "\n");
 	return len;
 }


-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@xxxxxxx> 1.650.933.1373
-
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/