From: KOSAKI Motohiro Date: Wed, 19 May 2010 00:37:41 +0000 (+0900) Subject: cpumask: fix compat getaffinity X-Git-Tag: v2.6.35-rc1~501 X-Git-Url: http://git.openpandora.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=fa9dc265ace9774e62f0e31108e5f47911124bda;p=pandora-kernel.git cpumask: fix compat getaffinity Commit a45185d2d "cpumask: convert kernel/compat.c" broke libnuma, which abuses sched_getaffinity to find out NR_CPUS in order to parse /sys/devices/system/node/node*/cpumap. On NUMA systems with less than 32 possibly CPUs, the current compat_sys_sched_getaffinity now returns '4' instead of the actual NR_CPUS/8, which makes libnuma bail out when parsing the cpumap. The libnuma call sched_getaffinity(0, bitmap, 4096) at first. It mean the libnuma expect the return value of sched_getaffinity() is either len argument or NR_CPUS. But it doesn't expect to return nr_cpu_ids. Strictly speaking, userland requirement are 1) Glibc assume the return value mean the lengh of initialized of mask argument. E.g. if sched_getaffinity(1024) return 128, glibc make zero fill rest 896 byte. 2) Libnuma assume the return value can be used to guess NR_CPUS in kernel. It assume len-arg Acked-by: Rusty Russell Acked-by: Arnd Bergmann Reported-by: Ken Werner Cc: stable@kernel.org Cc: Andi Kleen Signed-off-by: Linus Torvalds --- Reading git-diff-tree failed