RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:

There is a global pointer named 'numa_all_cpus_ptr' which is broken in that it doesn't function as documented.  It is supposed to be set to ' a bitmask that is allocated by the library with bits representing all cpus on which the calling  thread  may  execute.  However, this seems to not work when the bitmask is set to only CPU0

$./t
numa_all_cpus_ptr: 1111111111111111111111111111111100
Number of CPUS in numa_all_cpus_ptr: 32

$ taskset -c 4 ./t
numa_all_cpus_ptr: 0000100000000000000000000000000000
Number of CPUS in numa_all_cpus_ptr: 1

$ taskset -c 0 ./t
numa_all_cpus_ptr: 1111111111111111111111111111111100
Number of CPUS in numa_all_cpus_ptr: 32

$ taskset -c 1 ./t
numa_all_cpus_ptr: 0100000000000000000000000000000000
Number of CPUS in numa_all_cpus_ptr: 1

Note that the taskset -c0 ./t case should only have 1 bit set in the 0th position.  So it must be the code that parses /proc/self/stat Cpus_allowed.

Version-Release number of selected component (if applicable):
numactl-2.0.3-9.el6

How reproducible:
100%

Steps to Reproduce:
1.  See above
  
Actual results:
Broken

Expected results:
Not Broken

Additional info:
LLNL has requested this bug be public.

Created attachment 578663 [details]
Reproducer

gcc -o t -lnuma t.c

Created attachment 578665 [details]
Proposed Patch

commit 346e427204fba80e86d6ebd8965610b89dc5c7d6
Author: Mark A. Grondona <mgrondona>
Date:   Tue Mar 27 15:51:28 2012 -0700

    libnuma: fix numa_all_cpus_ptr when bound to cpu0
    
    A bug in the test for invalid maxproccpu leads to resetting the
    numa_all_cpus_ptr mask when the cpu affinity mask of the current
    task only contains CPU0. This leads to numa_all_cpus_ptr having
    all CPUs instead of just one.
    
    Fix the test to be < 0 instead of <= 0 -- 0 is a valid CPU number.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0401.html