Re: [linux-next:master 2890/4758] ld.lld: error: undefined symbol: phys_to_target_node

[Randy Dunlap <rdunlap@infradead.org>]

On 9/5/20 2:24 PM, Randy Dunlap wrote:
> On 9/3/20 5:31 AM, Joao Martins wrote:
>> On 9/3/20 6:49 AM, kernel test robot wrote:
>>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>>> head:   4442749a203151a319a5bb8d0b983b84253a6931
>>> commit: bd295a352cfa24e5110a53f978edb48b7c21ff8f [2890/4758] ACPI: HMAT: attach a device for each soft-reserved range
>>> config: x86_64-randconfig-a002-20200902 (attached as .config)
>>> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 224d8153b53b16cf535ea1a55afdfe1ec5b1374f)
>>> reproduce (this is a W=1 build):
>>>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>>>         chmod +x ~/bin/make.cross
>>>         # install x86_64 cross compiling tool for clang build
>>>         # apt-get install binutils-x86-64-linux-gnu
>>>         git checkout bd295a352cfa24e5110a53f978edb48b7c21ff8f
>>>         # save the attached .config to linux build tree
>>>         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 
>>>
>>> If you fix the issue, kindly add following tag as appropriate
>>> Reported-by: kernel test robot <lkp@intel.com>
>>>
>>> All errors (new ones prefixed by >>):
>>>
>>>>> ld.lld: error: undefined symbol: phys_to_target_node
>>>    >>> referenced by device.c:84 (drivers/dax/hmem/device.c:84)
>>>    >>>               dax/hmem/device.o:(hmem_register_one) in archive drivers/built-in.a
>>>
>> This would require the proposed fix below the scissors mark.
>>
>> I had reported this failure before, but it needed an adjustment so I'm re-sending it.
>>
>> --------------------------->8----------------------------
>>
>> From 622c1297b7d76a319b07a29192fe9bfe5c2b6b7c Mon Sep 17 00:00:00 2001
>> From: Joao Martins <joao.m.martins@oracle.com>
>> Date: Tue, 1 Sep 2020 08:06:35 -0400
>> Subject: [PATCH] device-dax: Require NUMA_KEEP_MEMINFO for
>>  phys_to_target_node()
>>
>> phys_to_target_node() and memory_add_physaddr_to_nid() are only defined
>> with both CONFIG_NUMA=y and CONFIG_MEMORY_HOTPLUG=y.  Oherwise we see:
>>
>> drivers/dax/hmem/device.o: in function `hmem_register_one':
>> drivers/dax/hmem/device.c:85: undefined reference to `phys_to_target_node'
>>
>> lkp also reports such build failures:
>>
>> ld.lld: error: undefined symbol: phys_to_target_node
>>
>> X86 is a special case in which both can be defined without depending on
>> MEMORY_HOTPLUG=y. The other case is powerpc (for
>> memory_add_physaddr_to_nid) but like ARM64 dependencies, the
>> arch-specific override requires CONFIG_NUMA and CONFIG_MEMORY_HOTPLUG.
>>
>> In all cases this ends up depending on CONFIG_NUMA_KEEP_MEMINFO to
>> signal the presence of phys_to_target_node() which is what
>> CONFIG_DEV_DAX_HMEM_DEVICES should depend on. Additionally, the X86
>> arch-override is not selected unless X86_PMEM_LEGACY=y. So on
>> CONFIG_DEV_DAX_HMEM we select CONFIG_NUMA_KEEP_INFO ourselves if both
>> NUMA and X86 are set.
>>
>> Reported-by: kernel test robot <lkp@intel.com>
>> Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
>> ---
>>  drivers/dax/Kconfig | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
>> index a66dff78f298..567428e10b7b 100644
>> --- a/drivers/dax/Kconfig
>> +++ b/drivers/dax/Kconfig
>> @@ -35,6 +35,7 @@ config DEV_DAX_PMEM
>>  config DEV_DAX_HMEM
>>         tristate "HMEM DAX: direct access to 'specific purpose' memory"
>>         depends on EFI_SOFT_RESERVE
>> +       select NUMA_KEEP_MEMINFO if (NUMA && X86)
>>         default DEV_DAX
>>         help
>>           EFI 2.8 platforms, and others, may advertise 'specific purpose'
>> @@ -49,6 +50,7 @@ config DEV_DAX_HMEM
>>           Say M if unsure.
>>
>>  config DEV_DAX_HMEM_DEVICES
>> +       depends on NUMA_KEEP_MEMINFO # for phys_to_target_node()
>>         depends on DEV_DAX_HMEM && DAX=y
>>         def_bool y
>>
> 
> Hi,
> 
> There is also this patch from Matt Fleming from last year that I have
> successfully tested (built) on ppc64 and arch/sh/, where build errors were reported.
> 
> https://lore.kernel.org/lkml/20191223164220.GA14394@codeblueprint.co.uk/
> 
> but Matt doesn't seem to be replying to any emails about this patch...
> 

OK, Matt's patch doesn't fix this x86_64 dax + hmem build error, so
apparently Joao's patch is needed.

-- 
~Randy