[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 2 Dec 2014 22:19:58 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: __sched_cpucount returns garbage
On Tue, Dec 02, 2014 at 09:48:51PM -0500, Rich Felker wrote:
> > OK, rereading it:
> > We're probably using HAVE_SCHED_GETAFFINITY_LIKE_GLIBC, and CPU_COUNT is
> > defined.
> > So it ostensibly should be more-or-less:
> > if (sched_getaffinity (0, sizeof (set), &set) == 0)
> > {
> > unsigned long count;
> > count = CPU_COUNT(&set);
> > if (count > 0)
> > return count;
> > }
> > BUT... isolating that snippet gives me the expected results...if
> > I initialize set to 0, which they *don't*.
> > So I guess it's the missing initialization.
>
> I think it's a kernel quirk. It looks like the kernel only fills the
> part of the cpuset up to the actual number of cpus the kernel knows
> about or supports. The syscall then returns a value (bits? bytes?)
> indicating the amount filled, and userspace is responsible for
> zero-filling the rest and returning zero. I'll look into the details
> and fix it.
Should be fixed as of commit a56e339419c1a90f8a85f86621f3c73945e07b23.
The subsequent commit 66140b0c926ed097f2cb7474863523e4af351f5b also
fixes the return value for the pthread_*_np variants.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
