From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: <linux-mm@kvack.org>, <linux-acpi@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>, <x86@kernel.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>, <linux-pci@vger.kernel.org>,
<martin@geanix.com>, Ingo Molnar <mingo@redhat.com>,
<linux-ia64@vger.kernel.org>, Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Thomas Gleixner <tglx@linutronix.de>, <linuxarm@huawei.com>,
Dan Williams <dan.j.williams@intel.com>,
Song Bao Hua <song.bao.hua@hisilicon.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>
Subject: [PATCH v2 6/6] irq-chip/gic-v3-its: Fix crash if ITS is in a proximity domain without processor or memory
Date: Sat, 18 Jul 2020 01:59:59 +0800 [thread overview]
Message-ID: <20200717175959.899775-7-Jonathan.Cameron@huawei.com> (raw)
In-Reply-To: <20200717175959.899775-1-Jonathan.Cameron@huawei.com>
Note this crash is present before any of the patches in this series, but
as explained below it is highly unlikely anyone is shipping a firmware that
causes it. Tests were done using an overriden SRAT.
On ARM64, the gic-v3 driver directly parses SRAT to locate GIC Interrupt
Translation Service (ITS) Affinity Structures. This is done much later
in the boot than the parses of SRAT which identify proximity domains.
As a result, an ITS placed in a proximity domain that is not defined by
another SRAT structure will result in a NUMA node that is not completely
configured and a crash.
ITS [mem 0x202100000-0x20211ffff]
ITS@0x0000000202100000: Using ITS number 0
Unable to handle kernel paging request at virtual address 0000000000001a08
...
Call trace:
__alloc_pages_nodemask+0xe8/0x338
alloc_pages_node.constprop.0+0x34/0x40
its_probe_one+0x2f8/0xb18
gic_acpi_parse_madt_its+0x108/0x150
acpi_table_parse_entries_array+0x17c/0x264
acpi_table_parse_entries+0x48/0x6c
acpi_table_parse_madt+0x30/0x3c
its_init+0x1c4/0x644
gic_init_bases+0x4b8/0x4ec
gic_acpi_init+0x134/0x264
acpi_match_madt+0x4c/0x84
acpi_table_parse_entries_array+0x17c/0x264
acpi_table_parse_entries+0x48/0x6c
acpi_table_parse_madt+0x30/0x3c
__acpi_probe_device_table+0x8c/0xe8
irqchip_init+0x3c/0x48
init_IRQ+0xcc/0x100
start_kernel+0x33c/0x548
ACPI 6.3 allows any set of Affinity Structures in SRAT to define a proximity
domain. However, as we do not see this crash, we can conclude that no
firmware is currently placing an ITS in a node that is separate from
those containing memory and / or processors.
We could modify the SRAT parsing behavior to identify the existence
of Proximity Domains unique to the ITS structures, and handle them as
a special case of a generic initiator (once support for those merges).
This patch avoids the complexity that would be needed to handle this corner
case, by not allowing the ITS entry parsing code to instantiate new NUMA
Nodes. If one is encountered that does not already exist, then NO_NUMA_NODE
is assigned and a warning printed just as if the value had been greater than
allowed NUMA Nodes.
"SRAT: Invalid NUMA node -1 in ITS affinity"
Whilst this does not provide the full flexibility allowed by ACPI,
it does fix the problem. We can revisit a more sophisticated solution if
needed by future platforms.
Change is simply to replace acpi_map_pxm_to_node with pxm_to_node reflecting
the fact a new mapping is not created.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
drivers/irqchip/irq-gic-v3-its.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 6a5a87fc4601..c26862a074da 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -5248,7 +5248,12 @@ static int __init gic_acpi_parse_srat_its(union acpi_subtable_headers *header,
return -EINVAL;
}
- node = acpi_map_pxm_to_node(its_affinity->proximity_domain);
+ /*
+ * Note that in theory a new proximity node could be created by this
+ * entry as it is an SRAT resource allocation structure.
+ * We do not currently support doing so.
+ */
+ node = pxm_to_node(its_affinity->proximity_domain);
if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
pr_err("SRAT: Invalid NUMA node %d in ITS affinity\n", node);
--
2.19.1
next prev parent reply other threads:[~2020-07-17 18:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-17 17:59 [PATCH v2 0/6] ACPI: Only create NUMA nodes from entries in SRAT or SRAT emulation Jonathan Cameron
2020-07-17 17:59 ` [PATCH v2 1/6] ACPI: Add out of bounds and numa_off protections to pxm_to_node Jonathan Cameron
2020-07-18 5:09 ` Song Bao Hua (Barry Song)
2020-07-17 17:59 ` [PATCH v2 2/6] ACPI: Do not create new NUMA domains from ACPI static tables that are not SRAT Jonathan Cameron
2020-07-18 5:14 ` Song Bao Hua (Barry Song)
2020-07-17 17:59 ` [PATCH v2 3/6] ACPI: Remove side effect of partly creating a node in acpi_map_pxm_to_online_node Jonathan Cameron
2020-07-17 17:59 ` [PATCH v2 4/6] ACPI: Rename acpi_map_pxm_to_online_node to pxm_to_online_node Jonathan Cameron
2020-07-17 17:59 ` [PATCH v2 5/6] ACPI: Remove side effect of partly creating a node in acpi_get_node Jonathan Cameron
2020-07-18 5:17 ` Song Bao Hua (Barry Song)
2020-07-17 17:59 ` Jonathan Cameron [this message]
2020-07-20 2:02 ` [PATCH v2 0/6] ACPI: Only create NUMA nodes from entries in SRAT or SRAT emulation Hanjun Guo
2020-07-28 16:20 ` Jonathan Cameron
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=20200717175959.899775-7-Jonathan.Cameron@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=fenghua.yu@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=lorenzo.pieralisi@arm.com \
--cc=martin@geanix.com \
--cc=mingo@redhat.com \
--cc=song.bao.hua@hisilicon.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--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;
as well as URLs for NNTP newsgroup(s).