linux-kernel - Re: [PATCH] x86/platform/uv: Use alternate source for socket to node data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 1 Sep 2023 10:18:20 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Steve Wahl <steve.wahl@....com>,
        Dimitri Sivanich <dimitri.sivanich@....com>,
        Russ Anderson <russ.anderson@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/platform/uv: Use alternate source for socket to node
 data

On 8/7/23 07:17, Steve Wahl wrote:
> When nr_cpus is set to a smaller number than actually present, the
> cpu_to_node() mapping information for unused CPUs is not available to
> build_socket_tables().  This results in an incomplete table and will
> later cause use of a -1 value for some array indexing, and eventual
> kernel page faults.
> 
> Switch to using the __apicid_to_node array, which still contains all
> the information mapping apicids to nodes, even for CPUs disabled with
> a reduced nr_cpus setting.

Before, the lookup went:

	CPU => APICID => SOCKET

But when the CPU wasn't present, there wasn't a way to start this lookup.

So, instead of looping over all CPUs, looking up their APICIDs and
mapping those to sockets, just take CPUs out of the equation entirely.

Loop over all APICIDs which are mapped to a valid NUMA node.  Then just
extract the socket-id from the APICID.

Right?

That seems sane enough.  It's also way less code than the previous approach.