From patchwork Tue Aug 18 14:24:30 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jonathan Cameron X-Patchwork-Id: 247896 Delivered-To: patch@linaro.org Received: by 2002:a54:3b12:0:0:0:0:0 with SMTP id j18csp3179043ect; Tue, 18 Aug 2020 07:28:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwCtXnzEnXXsZPVL8nPMtmh9t2gDfBsNuQGoB+CEgxJVIZYTA5jpVGRs/DwpDF8rqTaLAnm X-Received: by 2002:a17:906:cb91:: with SMTP id mf17mr20096498ejb.527.1597760890952; Tue, 18 Aug 2020 07:28:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597760890; cv=none; d=google.com; s=arc-20160816; b=F4hPu1UMJP0ybjS+q33cqO+ebBD1bCDpTRDa+xj4AOdFNV5H9t5m8VUbeqsDMCY5PL nwAxv/bhuX2vsUrqPZS4s5C5EUoCawOLqGBrBavzBcJuMm3zQgyMk8MtlWqmtERvY17u MVOtjsa9y+6QfgoIn0oNJ/uYU7SUvMLnwWTkd17HW21JWs12/Xu2EHobcnTKI7VSSb3i PfICGWYOTXrDeHaZBOfU45a8IpQP8Uhvl1R/WIs4/MjsgTP2e3t2juhy24+hWd5bn+yr eOZno7CR8wNGwvA1bPSkjTbgP1Wgh4q6NNWP5NRvVYUg1rkGguxLuUaB1y449uhMn2ch uisw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=k5em7Vy2LmjV5Y2NdfR2IgKm9PZYI6cHeYiLN8RDARo=; b=l6T1pqOH3y3jXpGbMwWC0zXwYViZlzrk/yM96VqV9ZW56VqaLRU1Pwd/AuMXzlshao x9rh0NTek8r03wJu39WaTJOSZDtbZYTfG6Bm2TEGkxUhKC4I9LB19Di+gbp/3poa1cNg DUUCSDPlq3NG48CReqkE9xWgZMNs1ay1XD+2GTsNKaJms5uFk5jLjrI4FA9huyA2ZWme 8QjVU7xNIUumrR8rctbNUR/5x6O0KiErReAzQbUM6s3R441BmnIZkz0jjWbcsolMCQD0 2f9h8+ETnGuOTPyTtto7k+GdTVd7d2IOAIl4T5NZbUBKPpPRN4kkh7PDd06V8MrbKQ2L fNuA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-acpi-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h7si13339651ejx.254.2020.08.18.07.28.10; Tue, 18 Aug 2020 07:28:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-acpi-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-acpi-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726917AbgHRO2J (ORCPT + 7 others); Tue, 18 Aug 2020 10:28:09 -0400 Received: from lhrrgout.huawei.com ([185.176.76.210]:2622 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726660AbgHRO2J (ORCPT ); Tue, 18 Aug 2020 10:28:09 -0400 Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0DFD8528DCC75F4E9448; Tue, 18 Aug 2020 15:28:08 +0100 (IST) Received: from lhrphicprd00229.huawei.com (10.123.41.22) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 18 Aug 2020 15:28:07 +0100 From: Jonathan Cameron To: , , , CC: Lorenzo Pieralisi , Bjorn Helgaas , , , Ingo Molnar , , Tony Luck , Fenghua Yu , Thomas Gleixner , , Dan Williams , Song Bao Hua , Jonathan Cameron Subject: [PATCH v3 6/6] irq-chip/gic-v3-its: Fix crash if ITS is in a proximity domain without processor or memory Date: Tue, 18 Aug 2020 22:24:30 +0800 Message-ID: <20200818142430.1156547-7-Jonathan.Cameron@huawei.com> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20200818142430.1156547-1-Jonathan.Cameron@huawei.com> References: <20200818142430.1156547-1-Jonathan.Cameron@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.123.41.22] X-ClientProxiedBy: lhreml710-chm.china.huawei.com (10.201.108.61) To lhreml710-chm.china.huawei.com (10.201.108.61) X-CFilter-Loop: Reflected Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org 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 Reviewed-by: Hanjun Guo --- drivers/irqchip/irq-gic-v3-its.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) -- 2.19.1 diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 95f097448f97..b59b63ee3fa6 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -5263,7 +5263,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);