summaryrefslogtreecommitdiff
path: root/drivers
diff options
context:
space:
mode:
authorJan Beulich <jbeulich@suse.com>2024-05-29 10:39:10 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2024-06-21 15:40:29 +0300
commit22f742b8f738918f683198a18ec3c691acda14c4 (patch)
tree54d609349ce1f09b2eaade39304fd6cf89f7ac15 /drivers
parent10fc691c69fca4c558ff79b3f5014f5f26955767 (diff)
downloadlinux-22f742b8f738918f683198a18ec3c691acda14c4.tar.xz
memblock: make memblock_set_node() also warn about use of MAX_NUMNODES
commit e0eec24e2e199873f43df99ec39773ad3af2bff7 upstream. On an (old) x86 system with SRAT just covering space above 4Gb: ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0xfffffffff] hotplug the commit referenced below leads to this NUMA configuration no longer being refused by a CONFIG_NUMA=y kernel (previously NUMA: nodes only cover 6144MB of your 8185MB e820 RAM. Not used. No NUMA configuration found Faking a node at [mem 0x0000000000000000-0x000000027fffffff] was seen in the log directly after the message quoted above), because of memblock_validate_numa_coverage() checking for NUMA_NO_NODE (only). This in turn led to memblock_alloc_range_nid()'s warning about MAX_NUMNODES triggering, followed by a NULL deref in memmap_init() when trying to access node 64's (NODE_SHIFT=6) node data. To compensate said change, make memblock_set_node() warn on and adjust a passed in value of MAX_NUMNODES, just like various other functions already do. Fixes: ff6c3d81f2e8 ("NUMA: optimize detection of memory with no node id assigned by firmware") Signed-off-by: Jan Beulich <jbeulich@suse.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1c8a058c-5365-4f27-a9f1-3aeb7fb3e7b2@suse.com Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers')
0 files changed, 0 insertions, 0 deletions