From: Rusty Russell <rusty@rustcorp.com.au>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-kernel@vger.kernel.org, stable@kernel.org,
Andi Kleen <andi@firstfloor.org>, Ken Werner <ken.werner@web.de>
Subject: Re: cpumask: fix compat getaffinity
Date: Tue, 11 May 2010 09:13:47 +0930 [thread overview]
Message-ID: <201005110913.49162.rusty@rustcorp.com.au> (raw)
In-Reply-To: <201005081111.08720.arnd@arndb.de>
On Sat, 8 May 2010 06:41:08 pm Arnd Bergmann wrote:
> On Saturday 08 May 2010 10:30:47 Rusty Russell wrote:
> >
> > On Fri, 7 May 2010 10:15:49 pm Arnd Bergmann wrote:
> > > 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.
> >
> > Really? AFAICT the cpumap is printed using nr_cpu_ids too. Can you
> > give an example of what cpumap is on this system?
>
> On Ken's PS3 running the Fedora 12 kernel (2.6.32-something), the output
> from my memory is 00000000,00000000,00000000,00000003\n. NR_CPUs
> is 128, nr_cpu_ids is most likely 2.
Ah, I see. CONFIG_CPUMASK_OFFSTACK=n.
The nr_cpumask_bits is really an optimization for cpumask_first etc: making
it a constant (NR_CPUS) rather than a variable (nr_cpu_ids) for small NR_CPUS
makes it slightly faster.
However, we also use this for scnprintf et al, revealing this inconsistency.
Your patch would break libnuma on CONFIG_CPUMASK_OFFSTACK=y.
How's this?
cpumask: use nr_cpu_ids for printing and parsing cpumasks
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.
However, the result now returned reflects nr_cpu_ids, and
cpumask_scnprintf et al. use nr_cpumask_bits which is NR_CPUS (for
CONFIG_CPUMASK_OFFSTACK=n) or nr_cpu_ids (for
CONFIG_CPUMASK_OFFSTACK=y).
We should use nr_cpu_ids consistently.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: stable@kernel.org
diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -529,7 +529,7 @@ static inline void cpumask_copy(struct c
static inline int cpumask_scnprintf(char *buf, int len,
const struct cpumask *srcp)
{
- return bitmap_scnprintf(buf, len, cpumask_bits(srcp), nr_cpumask_bits);
+ return bitmap_scnprintf(buf, len, cpumask_bits(srcp), nr_cpu_ids);
}
/**
@@ -543,7 +543,7 @@ static inline int cpumask_scnprintf(char
static inline int cpumask_parse_user(const char __user *buf, int len,
struct cpumask *dstp)
{
- return bitmap_parse_user(buf, len, cpumask_bits(dstp), nr_cpumask_bits);
+ return bitmap_parse_user(buf, len, cpumask_bits(dstp), nr_cpu_ids);
}
/**
@@ -558,8 +558,7 @@ static inline int cpumask_parse_user(con
static inline int cpulist_scnprintf(char *buf, int len,
const struct cpumask *srcp)
{
- return bitmap_scnlistprintf(buf, len, cpumask_bits(srcp),
- nr_cpumask_bits);
+ return bitmap_scnlistprintf(buf, len, cpumask_bits(srcp), nr_cpu_ids);
}
/**
@@ -572,7 +571,7 @@ static inline int cpulist_scnprintf(char
*/
static inline int cpulist_parse(const char *buf, struct cpumask *dstp)
{
- return bitmap_parselist(buf, cpumask_bits(dstp), nr_cpumask_bits);
+ return bitmap_parselist(buf, cpumask_bits(dstp), nr_cpu_ids);
}
/**
next prev parent reply other threads:[~2010-05-10 23:44 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-07 12:45 cpumask: fix compat getaffinity Arnd Bergmann
2010-05-08 8:30 ` Rusty Russell
2010-05-08 9:11 ` Arnd Bergmann
2010-05-10 23:43 ` Rusty Russell [this message]
2010-05-11 1:47 ` KOSAKI Motohiro
2010-05-11 3:13 ` [stable] " Greg KH
2010-05-11 5:51 ` Rusty Russell
2010-05-11 6:25 ` KOSAKI Motohiro
2010-05-11 6:20 ` KOSAKI Motohiro
2010-05-11 15:20 ` Greg KH
2010-05-11 18:13 ` Arnd Bergmann
2010-05-11 21:36 ` Greg KH
2010-05-12 8:30 ` Milton Miller
2010-05-14 12:39 ` Rusty Russell
2010-05-17 6:04 ` KOSAKI Motohiro
2010-05-17 18:58 ` Arnd Bergmann
2010-05-18 0:57 ` Rusty Russell
2010-12-14 16:59 ` Josh Hunt
2010-12-15 14:40 ` Arnd Bergmann
2010-06-22 23:30 ` Rusty Russell
2010-05-11 9:05 ` Arnd Bergmann
2010-05-12 0:52 ` KOSAKI Motohiro
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=201005110913.49162.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=andi@firstfloor.org \
--cc=arnd@arndb.de \
--cc=ken.werner@web.de \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@kernel.org \
/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.