Re: [PATCH] x86/NUMA: don't pass MAX_NUMNODES to memblock_set_node()

[Dave Hansen <dave.hansen@intel.com>]

On 5/29/24 00:42, Jan Beulich wrote:
> On an (old) x86 system with SRAT just covering space above 4Gb:
> 
>     ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0xfffffffff] hotplug

OK, so you've got a system with buggy NUMA information.  It _used_ to
"refuse" the NUMA configuration.  Now it tries to move forward and
eventually does a NULL deref in memmap_init().

Right?

> 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.

This is a really oblique way of saying:

	... followed by a NULL deref in memmap_init() of
	NODE_DATA(MAX_NUMNODES).

> To compensate said change, avoid passing MAX_NUMNODES to
> memblock_set_node(). In turn numa_clear_kernel_node_hotplug()'s check
> then also needs adjusting.
> 
> Fixes: ff6c3d81f2e8 ("NUMA: optimize detection of memory with no node id assigned by firmware")

I was expecting to see MAX_NUMNODES checks in ff6c3d81f2e8 somewhere.
But I don't see any in the numa_meminfo_cover_memory() or
__absent_pages_in_range().

In other words, it's not completely clear why ff6c3d81f2e8 introduced
this problem.