From: Mike Rapoport <rppt@kernel.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH] memblock: make memblock_set_node() also warn about use of MAX_NUMNODES
Date: Thu, 30 May 2024 10:48:53 +0300 [thread overview]
Message-ID: <ZlgvZYBbDVemu-vA@kernel.org> (raw)
In-Reply-To: <1c8a058c-5365-4f27-a9f1-3aeb7fb3e7b2@suse.com>
On Wed, May 29, 2024 at 09:39:10AM +0200, Jan Beulich wrote:
> On an (old) x86 system with SRAT just covering space above 4Gb:
>
> ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0xfffffffff] hotplug
>
> the commit referenced below leads to this NUMA configuration no longer
> being refused by a CONFIG_NUMA=y kernel (previously
>
> NUMA: nodes only cover 6144MB of your 8185MB e820 RAM. Not used.
> No NUMA configuration found
> Faking a node at [mem 0x0000000000000000-0x000000027fffffff]
>
> was seen in the log directly after the message quoted above), because of
> memblock_validate_numa_coverage() checking for NUMA_NO_NODE (only). This
> in turn led to memblock_alloc_range_nid()'s warning about MAX_NUMNODES
> triggering, followed by a NULL deref in memmap_init() when trying to
> access node 64's (NODE_SHIFT=6) node data.
>
> To compensate said change, make memblock_set_node() warn on and adjust
> a passed in value of MAX_NUMNODES, just like various other functions
> already do.
>
> Fixes: ff6c3d81f2e8 ("NUMA: optimize detection of memory with no node id assigned by firmware")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Cc: stable@vger.kernel.org
> ---
> This still leaves MAX_NUMNODES uses in various other places.
> Interestingly
> https://lore.kernel.org/lkml/20170309034415.GA16588@WeideMacBook-Pro.local/T/#t
> was a more complete patch which, for an unclear reason, looks to never
> have made it anywhere. IOW the two memblock_set_node() invocations from x86'es
> numa_init() likely also want adjusting, among others.
They do. And I think that actually would be the right fix.
The warning and nid adjustment in memblock can be added for robustness, but
the calls to memblock_set_node() in x86 should be fixed regardless.
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1339,6 +1339,10 @@ int __init_memblock memblock_set_node(ph
> int start_rgn, end_rgn;
> int i, ret;
>
> + if (WARN_ONCE(nid == MAX_NUMNODES,
> + "Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead\n"))
> + nid = NUMA_NO_NODE;
> +
> ret = memblock_isolate_range(type, base, size, &start_rgn, &end_rgn);
> if (ret)
> return ret;
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2024-05-30 7:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-29 7:39 [PATCH] memblock: make memblock_set_node() also warn about use of MAX_NUMNODES Jan Beulich
2024-05-30 7:48 ` Mike Rapoport [this message]
2024-05-30 15:21 ` Jan Beulich
2024-05-31 9:40 ` Mike Rapoport
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=ZlgvZYBbDVemu-vA@kernel.org \
--to=rppt@kernel.org \
--cc=jbeulich@suse.com \
--cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.