From: Randy Dunlap <rdunlap@infradead.org>
To: Dan Williams <dan.j.williams@intel.com>,
Christoph Hellwig <hch@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
kernel test robot <lkp@intel.com>,
Joao Martins <joao.m.martins@oracle.com>, X86 ML <x86@kernel.org>,
Linux MM <linux-mm@kvack.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>
Subject: Re: [PATCH] x86/mm: Fix phys_to_target_node() export
Date: Mon, 2 Nov 2020 16:59:31 -0800 [thread overview]
Message-ID: <5b7fbe34-225f-4265-a368-5336ad5a16c1@infradead.org> (raw)
In-Reply-To: <CAPcyv4gj9ibFuBY1yt79CdKRgYAftdveXT1Ow4QvyRxri4jBRA@mail.gmail.com>
On 11/2/20 3:52 PM, Dan Williams wrote:
> On Sat, Oct 31, 2020 at 2:10 AM Christoph Hellwig <hch@infradead.org> wrote:
>>
>> On Thu, Oct 29, 2020 at 07:29:45PM -0700, Dan Williams wrote:
>>> The core-mm has a default __weak implementation of phys_to_target_node()
>>> when the architecture does not override it. That symbol is exported
>>> for modules. However, while the export in mm/memory_hotplug.c exported
>>> the symbol in the configuration cases of:
>>
>> Which just means that we should never export weak symbols. So instead
>> of hacking around this introduce a symbol that indicates that the
>> architecture impements phys_to_target_node, and don't defined it at all
>> in common code for that case.
>
> So I agree with this, but it made me realize that the way
> memory_add_physaddr_to_nid() was defined as an exported weak symbol is
> similarly broken.
>
>>> --- a/mm/memory_hotplug.c
>>> +++ b/mm/memory_hotplug.c
>>> @@ -365,9 +365,14 @@ int __weak phys_to_target_node(u64 start)
>>> start);
>>> return 0;
>>> }
>>> +
>>> +/* If the arch did not export a strong symbol, export the weak one. */
>>> +#ifndef CONFIG_NUMA_KEEP_MEMINFO
>>> EXPORT_SYMBOL_GPL(phys_to_target_node);
>>> #endif
>>>
>>> +#endif
>>
>> i.e. move the ifdef to include the actual phys_to_target_node
>> definition, and remove the __weak from it here.
>
> The trick is finding an arch common way to pick up the presence of the
> phys_to_target_node() override, and it still has the wart of ifdefery
> in C code.
>
> I went a bit deeper and moved all the fallback routines to
> linux/numa.h and the overrides in all archs that care to
> asm/sparsemem.h. Note that asm/sparsemem.h was not my first choice,
> but it happened to be where powerpc was already defining its
> phys-addr-to-node-id infrastructure, and my first choice header,
> asm/numa.h, is not universally available.
>
> The attached patch is going through some kbuild-robot exposure to make
> sure I did not break anything else.
>
Works for me. Thanks.
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
--
~Randy
next prev parent reply other threads:[~2020-11-03 0:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-30 2:29 Dan Williams
2020-10-30 3:05 ` Randy Dunlap
2020-10-30 11:34 ` David Hildenbrand
2020-10-31 1:54 ` Dan Williams
2020-10-31 3:01 ` Thomas Gleixner
2020-10-31 4:45 ` Dan Williams
2020-10-31 9:10 ` Christoph Hellwig
2020-11-02 23:52 ` Dan Williams
2020-11-03 0:59 ` Randy Dunlap [this message]
2020-11-03 8:33 ` Christoph Hellwig
2020-11-03 10:39 ` Thomas Gleixner
2020-11-04 1:38 ` Andrew Morton
2020-11-04 1:49 ` Dan Williams
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=5b7fbe34-225f-4265-a368-5336ad5a16c1@infradead.org \
--to=rdunlap@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=hch@infradead.org \
--cc=joao.m.martins@oracle.com \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=lkp@intel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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