This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/15630] Fix use of cpu_set_t with sched_getaffinity when booted on a system with more than 1024 possible cpus.
- From: "fweimer at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 18 May 2015 15:55:57 +0000
- Subject: [Bug libc/15630] Fix use of cpu_set_t with sched_getaffinity when booted on a system with more than 1024 possible cpus.
- Auto-submitted: auto-generated
- References: <bug-15630-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=15630
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fweimer at redhat dot com
--- Comment #2 from Florian Weimer <fweimer at redhat dot com> ---
Maybe addressing this should also fix this design issue with the cpu_set_t
functions:
CPU_ALLOC returns a set which is capable of storing more CPUs than the user
requested because the request is rounded up to the next multiple of sizeof
(long) * CHAR_BIT CPUs. This is reflected in the return value of
CPU_ALLOC_SIZE. As a result, the sched_getaffinity call in
set = CPU_ALLOC (count);
sched_getaffinity (0, CPU_ALLOC_SIZE (count), set);
can succeed even if count is smaller than the maximum number of relevant CPUs.
This defeats the purpose of the EINVAL error return code in case the specified
CPU set is not large enough.
--
You are receiving this mail because:
You are on the CC list for the bug.