sysconf(_SC_NPROCESSORS_CONF) returns the wrong value

[Jonathan Rajotte-Julien <jonathan.rajotte-julien@efficios.com>]

Hi all,

We are currently in the process of making sure that lttng [1] (linux tracer) run
smoothly on system using musl (Yocto, Alpine etc.). Most things work
fine. Still, we currently have tests that are failing due to an issue regarding
the reported number of configured processors on the system (__SC_NPROCESSORS_CONF).
Note that users of LTTng are also affected by this if they chose to modify the
sched affinity of their instrumented apps. This is relatively a big deal for us.

Long story short, we start an app with "taskset -c 0" and we need to allocate
data structure internally but using the number of configured processors not the
number of online processors. To do so we call sysconf(__SC_NPROCESSORS_CONF).
Slight problem: the value returned is the _SC_NPROCESSORS_ONLN value instead of
__SC_NPROCESSORS_CONF.

From src/conf/sysconf.c:196

 case JT_NPROCESSORS_CONF & 255:
 case JT_NPROCESSORS_ONLN & 255: ;
   unsigned char set[128] = {1};
   int i, cnt;
   __syscall(SYS_sched_getaffinity, 0, sizeof set, set);
   for (i=cnt=0; i<sizeof set; i++)
     for (; set[i]; set[i]&=set[i]-1, cnt++);
   return cnt;

A simple command line to show this:

  taskset -c 0 nproc --all

This is equivalent to asking sysconf(__SC_NPROCESSORS_CONF).

On 4 cpu system using glibc:

  $ taskset -c 0 nproc --all
  4

On the same system using musl:

  $ taskset -c 0 nproc --all
  1

And as for _SC_NPROCESSORS_ONLN, we can use:

  taskset -c 0 nproc

Using glibc:
  $ taskset -c 0 nproc
  1

Using musl:
  $ taskset -c 0 nproc
  1

No problem there.

Not sure where to go from there. We will probably end-up having a fallback for
musl that will probably consist of parsing /sys/ like glibc does.

Still we wanted to get your feedback on the matter.

Cheers

-- 
Jonathan Rajotte-Julien
EfficiOS