[PATCH] nvme-multipath: fix flex array size in struct nvme_ns_head

[Nilay Shroff]

On 5/27/26 7:19 PM, Keith Busch wrote:
> On Wed, May 27, 2026 at 11:50:00AM +0530, Nilay Shroff wrote:
>> Fix this by allocating the flexible array using nr_node_ids instead
>> of num_possible_nodes(). Since nr_node_ids represents the maximum
>> possible NUMA node IDs, indexing current_path[] using numa_node_id()
>> becomes safe even on systems with sparse node IDs.
> 
> What is the largest nr_node_ids we can reasonably expect to see? I don't
> want to end up trying to allocate a billion entry sparse array just to
> index a tiny fraction of them. Not that we didn't have a similar problem
> before, but this patch makes it clear we haven't been checking.

The nr_node_ids value is bounded by MAX_NUMNODES, which is a compile-time
constant derived from CONFIG_NODES_SHIFT:

#define MAX_NUMNODES    (1 << CONFIG_NODES_SHIFT)

nr_node_ids itself cannot exceed MAX_NUMNODES.

For example:

x86 (arch/x86/Kconfig):
config NODES_SHIFT
         int "Maximum NUMA Nodes (as a power of 2)" if !MAXSMP
         range 1 10
         default "10" if MAXSMP
         default "6" if X86_64
         default "3"
         depends on NUMA

arm64 (arch/arm64/Kconfig):
config NODES_SHIFT
         int "Maximum NUMA Nodes (as a power of 2)"
         range 1 10
         default "4"
         depends on NUMA

powerpc (arch/powerpc/Kconfig):
config NODES_SHIFT
         int
         default "8" if PPC64
         default "4"
         depends on NUMA

Looking across the architectures supported by Linux, CONFIG_NODES_SHIFT
appears to be capped at 10, which gives:

MAX_NUMNODES = 1 << 10 = 1024

So in practice, nr_node_ids should not exceed 1024.

This means the flexible array allocation remains bounded and should not grow
into an unreasonably large sparse allocation.

Thanks,
--Nilay