linux-kernel - Re: [PATCH v2 2/2] arm64: ACPI: NUMA: initialize all values of acpi_early_node_map to NUMA_NO

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]

Message-ID: <ZrJQsuOguTkbpMI2@lpieralisi>
Date: Tue, 6 Aug 2024 18:34:58 +0200
From: Lorenzo Pieralisi <lpieralisi@...nel.org>
To: Catalin Marinas <catalin.marinas@....com>
Cc: Haibo Xu <haibo1.xu@...el.com>, ajones@...tanamicro.com,
	sunilvl@...tanamicro.com, xiaobo55x@...il.com,
	Anshuman Khandual <anshuman.khandual@....com>,
	Will Deacon <will@...nel.org>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	Hanjun Guo <guohanjun@...wei.com>,
	James Morse <james.morse@....com>,
	"Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v2 2/2] arm64: ACPI: NUMA: initialize all values of
 acpi_early_node_map to NUMA_NO_NODE

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@...tanamicro.com>
> > Suggested-by: Andrew Jones <ajones@...tanamicro.com>
> > Signed-off-by: Haibo Xu <haibo1.xu@...el.com>
> > Reviewed-by: Anshuman Khandual <anshuman.khandual@....com>
> > Reviewed-by: Sunil V L <sunilvl@...tanamicro.com>
> > Reviewed-by: Andrew Jones <ajones@...tanamicro.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@....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@...nel.org>