[PATCH v2 2/2] arm64: ACPI: NUMA: initialize all values of acpi_early_node_map to NUMA_NO_NODE
Lorenzo Pieralisi
lpieralisi at kernel.org
Tue Aug 6 09:34:58 PDT 2024
On Mon, Aug 05, 2024 at 04:21:34PM +0100, Catalin Marinas wrote:
> On Mon, Aug 05, 2024 at 11:30:24AM +0800, Haibo Xu wrote:
> > Currently, only acpi_early_node_map[0] was initialized to NUMA_NO_NODE.
> > To ensure all the values were properly initialized, switch to initialize
> > all of them to NUMA_NO_NODE.
> >
> > Fixes: e18962491696 ("arm64: numa: rework ACPI NUMA initialization")
> > Reported-by: Andrew Jones <ajones at ventanamicro.com>
> > Suggested-by: Andrew Jones <ajones at ventanamicro.com>
> > Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
> > Reviewed-by: Anshuman Khandual <anshuman.khandual at arm.com>
> > Reviewed-by: Sunil V L <sunilvl at ventanamicro.com>
> > Reviewed-by: Andrew Jones <ajones at ventanamicro.com>
> > ---
> > arch/arm64/kernel/acpi_numa.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
> > index 0c036a9a3c33..2465f291c7e1 100644
> > --- a/arch/arm64/kernel/acpi_numa.c
> > +++ b/arch/arm64/kernel/acpi_numa.c
> > @@ -27,7 +27,7 @@
> >
> > #include <asm/numa.h>
> >
> > -static int acpi_early_node_map[NR_CPUS] __initdata = { NUMA_NO_NODE };
> > +static int acpi_early_node_map[NR_CPUS] __initdata = { [0 ... NR_CPUS - 1] = NUMA_NO_NODE };
Bah, silly me, sorry.
> Acked-by: Catalin Marinas <catalin.marinas at arm.com>
>
> The patch makes sense but is there any issue currently without it?
I suspect there might be - a cpu associated with NUMA node 0 when it is
actually unspecified in ACPI tables (well, probably not even a real
world bug - I don't know, that's why it was not caught earlier I
believe) but still.
> Trying to assess whether it needs a stable backport.
Whether that's a real bug or not depends on deployed ACPI firmware
tables; if all cores have a proximity domain assigned in the
respective SRAT entries this patch is irrelevant but
technically it is a bug to fix, yes.
Backporting would make sense, it should be innocuous.
Acked-by: Lorenzo Pieralisi <lpieralisi at kernel.org>
More information about the linux-riscv
mailing list