Re: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

Dan Williams
2025-04-09T04:14:58Z

Yuquan Wang wrote:
>
> > [add loongarch folks, cc linux-cxl ]
> >
> > kernel test robot wrote:
> > > Hi Yuquan,
> > >
> > > kernel test robot noticed the following build errors:
> > >
> > > [auto build test ERROR on akpm-mm/mm-everything]
> > >
> > > url: https://github.com/intel-lab-lkp/linux/commits/Yuquan-Wang/mm-numa_memblks-introduce-numa_add_reserved_memblk/20250328-172428
> > > base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
> > > patch link: https://lore.kernel.org/r/20250328092132.2695299-1-wangyuquan1236%40phytium.com.cn
> > > patch subject: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk
> > > config: loongarch-randconfig-002-20250328 (https://download.01.org/0day-ci/archive/20250328/202503282026.QNaOAK79-lkp@intel.com/config)
> > > compiler: loongarch64-linux-gcc (GCC) 14.2.0
> > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250328/202503282026.QNaOAK79-lkp@intel.com/reproduce)
> > >
> > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > the same patch/commit), kindly add following tags
> > > | Reported-by: kernel test robot <lkp@intel.com>
> > > | Closes: https://lore.kernel.org/oe-kbuild-all/202503282026.QNaOAK79-lkp@intel.com/
> > >
> > > All errors (new ones prefixed by >>):
> > >
> > > In file included from include/linux/build_bug.h:5,
> > > from include/linux/container_of.h:5,
> > > from include/linux/list.h:5,
> > > from include/linux/module.h:12,
> > > from drivers/acpi/numa/srat.c:10:
> > > drivers/acpi/numa/srat.c: In function 'acpi_parse_cfmws':
> > > >> drivers/acpi/numa/srat.c:461:13: error: implicit declaration of function 'numa_add_reserved_memblk' [-Wimplicit-function-declaration]
> > > 461 | if (numa_add_reserved_memblk(node, start, end) < 0) {
> > > | ^~~~~~~~~~~~~~~~~~~~~~~~
> >
> > So it looks like loongarch was left out of the numa_memblks conversion:
> > 87482708210f ("mm: introduce numa_memblks")
> >
> > I think the update needed is something like this (untested):
> >
> > diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
> > index 2b8bd27a852f..cac16c827159 100644
> > --- a/arch/loongarch/Kconfig
> > +++ b/arch/loongarch/Kconfig
> > @@ -183,6 +183,7 @@ config LOONGARCH
> > select MODULES_USE_ELF_RELA if MODULES
> > select NEED_PER_CPU_EMBED_FIRST_CHUNK
> > select NEED_PER_CPU_PAGE_FIRST_CHUNK
> > + select NUMA_MEMBLKS
> > select OF
> > select OF_EARLY_FLATTREE
> > select PCI
> > diff --git a/arch/loongarch/include/asm/numa.h b/arch/loongarch/include/asm/numa.h
> > index b5f9de9f102e..bbf9f70bd25f 100644
> > --- a/arch/loongarch/include/asm/numa.h
> > +++ b/arch/loongarch/include/asm/numa.h
> > @@ -22,20 +22,6 @@ extern int numa_off;
> > extern s16 __cpuid_to_node[CONFIG_NR_CPUS];
> > extern nodemask_t numa_nodes_parsed __initdata;
> >
> > -struct numa_memblk {
> > - u64 start;
> > - u64 end;
> > - int nid;
> > -};
> > -
> > -#define NR_NODE_MEMBLKS (MAX_NUMNODES*2)
> > -struct numa_meminfo {
> > - int nr_blks;
> > - struct numa_memblk blk[NR_NODE_MEMBLKS];
> > -};
> > -
> > -extern int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> > -
> > extern void __init early_numa_add_cpu(int cpuid, s16 node);
> > extern void numa_add_cpu(unsigned int cpu);
> > extern void numa_remove_cpu(unsigned int cpu);
> > diff --git a/arch/loongarch/kernel/numa.c b/arch/loongarch/kernel/numa.c
> > index 84fe7f854820..57b21082e893 100644
> > --- a/arch/loongarch/kernel/numa.c
> > +++ b/arch/loongarch/kernel/numa.c
> > @@ -18,6 +18,7 @@
> > #include <linux/efi.h>
> > #include <linux/irq.h>
> > #include <linux/pci.h>
> > +#include <linux/numa_memblks.h>
> > #include <asm/bootinfo.h>
> > #include <asm/loongson.h>
> > #include <asm/numa.h>
> >
> > Could someone from the loongarch side propose the fixups needed here so
> > Yuquan can land this patch?
>
> Hi, Dan
>
> Should I wait for Loongarch folks's replies or draft a new patch for Loongarch
> to introduce numa_memblks according to your suggested code?

I would say go ahead and introduce the suggested changes. I think the
risk is low that copying what is done for numa_add_memblk() will break
something, and they can always jump in to fix that up if the worst case
happens.