Message ID | 853d7f74aa243f6f5999e203246f0d1ae92d2b61.1722828421.git.haibo1.xu@intel.com (mailing list archive) |
---|---|
State | Accepted |
Commit | b8c09eb344658fe7e7ccfe1e8002960b63f9449d |
Headers | show |
Series | [v2,1/2] RISC-V: ACPI: NUMA: initialize all values of acpi_early_node_map to NUMA_NO_NODE | expand |
On 2024/8/5 11:30, 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@ventanamicro.com> > Suggested-by: Andrew Jones <ajones@ventanamicro.com> > Signed-off-by: Haibo Xu <haibo1.xu@intel.com> > Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> > Reviewed-by: Sunil V L <sunilvl@ventanamicro.com> > Reviewed-by: Andrew Jones <ajones@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 }; > > int __init acpi_numa_get_nid(unsigned int cpu) > { Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Thanks Hanjun
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@ventanamicro.com> > Suggested-by: Andrew Jones <ajones@ventanamicro.com> > Signed-off-by: Haibo Xu <haibo1.xu@intel.com> > Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> > Reviewed-by: Sunil V L <sunilvl@ventanamicro.com> > Reviewed-by: Andrew Jones <ajones@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 }; Acked-by: Catalin Marinas <catalin.marinas@arm.com> The patch makes sense but is there any issue currently without it? Trying to assess whether it needs a stable backport.
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@ventanamicro.com> > > Suggested-by: Andrew Jones <ajones@ventanamicro.com> > > Signed-off-by: Haibo Xu <haibo1.xu@intel.com> > > Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> > > Reviewed-by: Sunil V L <sunilvl@ventanamicro.com> > > Reviewed-by: Andrew Jones <ajones@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@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@kernel.org>
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 }; int __init acpi_numa_get_nid(unsigned int cpu) {