From: Robert Richter <rrichter@amd.com>
To: Alison Schofield <alison.schofield@intel.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Dan Williams <dan.j.williams@intel.com>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-cxl@vger.kernel.org,
Derick Marks <derick.w.marks@intel.com>,
"H. Peter Anvin" <hpa@zytor.com>, Len Brown <lenb@kernel.org>
Subject: Re: [PATCH v6 1/7] x86/numa: Fix SRAT lookup of CFMWS ranges with numa_fill_memblks()
Date: Thu, 2 May 2024 14:11:05 +0200 [thread overview]
Message-ID: <ZjOC2bTWMO6NnSOk@rric.localdomain> (raw)
In-Reply-To: <ZjEZeHOlCSUMvMoD@aschofie-mobl2>
On 30.04.24 09:16:56, Alison Schofield wrote:
> On Tue, Apr 30, 2024 at 11:21:54AM +0200, Robert Richter wrote:
> > For configurations that have the kconfig option NUMA_KEEP_MEMINFO
> > disabled numa_fill_memblks() only returns with NUMA_NO_MEMBLK (-1).
> > SRAT lookup fails then because an existing SRAT memory range cannot be
> > found for a CFMWS address range. This causes the addition of a
> > duplicate numa_memblk with a different node id and a subsequent page
> > fault and kernel crash during boot.
> >
> > Fix this by making numa_fill_memblks() always available regardless of
> > NUMA_KEEP_MEMINFO.
> >
> > The fix also removes numa_fill_memblks() from sparsemem.h using
> > __weak.
> >
> > From Dan:
> >
> > """
> > It just feels like numa_fill_memblks() has absolutely no business being
> > defined in arch/x86/include/asm/sparsemem.h.
> >
> > The only use for numa_fill_memblks() is to arrange for NUMA nodes to be
> > applied to memory ranges hot-onlined by the CXL driver.
> >
> > It belongs right next to numa_add_memblk(), and I suspect
> > arch/x86/include/asm/sparsemem.h was only chosen to avoid figuring out
> > what to do about the fact that linux/numa.h does not include asm/numa.h
> > and that all implementations either provide numa_add_memblk() or select
> > the generic implementation.
> >
> > So I would prefer that this do the proper fix and get
> > numa_fill_memblks() completely out of the sparsemem.h path.
> >
> > Something like the following which boots for me.
> > """
> >
> > Note that the issue was initially introduced with [1]. But since
> > phys_to_target_node() was originally used that returned the valid node
> > 0, an additional numa_memblk was not added. Though, the node id was
> > wrong too, a message is seen then in the logs:
> >
> > kernel/numa.c: pr_info_once("Unknown target node for memory at 0x%llx, assuming node 0\n",
> >
> > [1] commit fd49f99c1809 ("ACPI: NUMA: Add a node and memblk for each
> > CFMWS not in SRAT")
> >
>
> For the commit log above -
> Perhaps the Dan quote can be reduced to a note about the implementation
> choice. Folks can look up the Lore thread if history is needed.
>
> For the code -
> Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Adjusted description, thanks.
-Robert
next prev parent reply other threads:[~2024-05-02 12:11 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-30 9:21 [PATCH v6 0/7] SRAT/CEDT fixes and updates Robert Richter
2024-04-30 9:21 ` [PATCH v6 1/7] x86/numa: Fix SRAT lookup of CFMWS ranges with numa_fill_memblks() Robert Richter
2024-04-30 14:48 ` Jonathan Cameron
2024-05-02 11:59 ` Robert Richter
2024-05-02 16:27 ` Jonathan Cameron
2024-04-30 16:16 ` Alison Schofield
2024-05-02 12:11 ` Robert Richter [this message]
2024-04-30 16:42 ` Dan Williams
2024-04-30 9:21 ` [PATCH v6 2/7] ACPI/NUMA: Remove architecture dependent remainings Robert Richter
2024-04-30 14:53 ` Jonathan Cameron
2024-04-30 16:01 ` Alison Schofield
2024-04-30 9:21 ` [PATCH v6 3/7] ACPI/NUMA: Squash acpi_numa_slit_init() into acpi_parse_slit() Robert Richter
2024-04-30 14:54 ` Jonathan Cameron
2024-04-30 16:01 ` Alison Schofield
2024-04-30 9:21 ` [PATCH v6 4/7] ACPI/NUMA: Squash acpi_numa_memory_affinity_init() into acpi_parse_memory_affinity() Robert Richter
2024-04-30 15:03 ` Jonathan Cameron
2024-04-30 16:01 ` Alison Schofield
2024-04-30 9:21 ` [PATCH v6 5/7] ACPI/NUMA: Return memblk modification state from numa_fill_memblks() Robert Richter
2024-04-30 15:14 ` Jonathan Cameron
2024-04-30 15:49 ` Alison Schofield
2024-04-30 17:05 ` Dan Williams
2024-05-02 12:45 ` Robert Richter
2024-04-30 9:21 ` [PATCH v6 6/7] ACPI/NUMA: Add log messages for memory ranges found in CEDT Robert Richter
2024-04-30 15:32 ` Jonathan Cameron
2024-04-30 15:49 ` Alison Schofield
2024-04-30 17:14 ` Dan Williams
2024-04-30 9:22 ` [PATCH v6 7/7] ACPI/NUMA: Print CXL Early Discovery Table (CEDT) Robert Richter
2024-04-30 15:55 ` Alison Schofield
2024-04-30 16:22 ` Jonathan Cameron
2024-05-02 12:53 ` Robert Richter
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=ZjOC2bTWMO6NnSOk@rric.localdomain \
--to=rrichter@amd.com \
--cc=alison.schofield@intel.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=derick.w.marks@intel.com \
--cc=hpa@zytor.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--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 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.