|
Message-ID: <20141203031958.GE4574@brightrain.aerifal.cx> 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.