linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Randy Dunlap <rdunlap@infradead.org>
To: Joao Martins <joao.m.martins@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vishal Verma <vishal.l.verma@intel.com>
Cc: kernel test robot <lkp@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	kbuild-all@lists.01.org, clang-built-linux@googlegroups.com,
	Linux Memory Management List <linux-mm@kvack.org>,
	Matt Fleming <matt@codeblueprint.co.uk>
Subject: Re: [linux-next:master 2890/4758] ld.lld: error: undefined symbol: phys_to_target_node
Date: Sat, 5 Sep 2020 19:58:40 -0700	[thread overview]
Message-ID: <fc34c6c9-5d77-3062-b977-26cb34eb577a@infradead.org> (raw)
In-Reply-To: <56f1cfa0-35e3-e88a-826b-3ebe2780b973@infradead.org>

On 9/5/20 2:58 PM, Randy Dunlap wrote:
> 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.
> 

OTOH, Joao's patch doesn't fix the ppc64 and arch/sh/ build errors.

I'd prefer to see one patch to fix all of these build errors...

-- 
~Randy



      reply	other threads:[~2020-09-06  2:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-03  5:49 kernel test robot
2020-09-03 12:31 ` Joao Martins
2020-09-05 21:24   ` Randy Dunlap
2020-09-05 21:58     ` Randy Dunlap
2020-09-06  2:58       ` Randy Dunlap [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fc34c6c9-5d77-3062-b977-26cb34eb577a@infradead.org \
    --to=rdunlap@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=clang-built-linux@googlegroups.com \
    --cc=dan.j.williams@intel.com \
    --cc=joao.m.martins@oracle.com \
    --cc=kbuild-all@lists.01.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=matt@codeblueprint.co.uk \
    --cc=vishal.l.verma@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox