From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4912AC2D0A8 for ; Mon, 28 Sep 2020 14:51:38 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D655721941 for ; Mon, 28 Sep 2020 14:51:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="M8+V0FqA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D655721941 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:Reply-To:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=qk8dN5vqMQRVwwnzMfaamlVSRTgc3Is7xoHRmR7BQLM=; b=M8+V0FqAw5WZgJyJ8hAVwB9y2D 7SDCMWSgoWOlujnFr2VeGDpFKSgd8beVNpzVype+3TYmWji8uJkgaEsHXeTWjhH8F3ng0k07E2mmt xNWHonPfoxflck7rzlrBFeWHq1bL4pBMiK8MJ/PfskR0PcuooYATJWnxbLC4MAutMvzek7QMfa4qd au9JsuUS7qkgM7Eh+0I0Bzua/EI7Web6EtwGLGJhkf865642PbMCvgnaiByDu1H7kU+Mo/p73hFdX hgBHJOCUma/C2mMAunjDHfg1tnnDQCCpS7RK2Hwktt0NwIIw7Qtik+q72wBmSVI2DYtjoL6afPSte oe15mkcg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kMuTr-0000DL-O8; Mon, 28 Sep 2020 14:50:19 +0000 Received: from out30-42.freemail.mail.aliyun.com ([115.124.30.42]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kMuTm-00007a-KI for linux-arm-kernel@lists.infradead.org; Mon, 28 Sep 2020 14:50:17 +0000 X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R171e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01e04420; MF=baolin.wang@linux.alibaba.com; NM=1; PH=DS; RN=6; SR=0; TI=SMTPD_---0UAN8ezQ_1601304597; Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0UAN8ezQ_1601304597) by smtp.aliyun-inc.com(127.0.0.1); Mon, 28 Sep 2020 22:49:57 +0800 Date: Mon, 28 Sep 2020 22:49:57 +0800 From: Baolin Wang To: Will Deacon Subject: Re: [PATCH] arm64: PCI: Validate the node before setting node id for root bus Message-ID: <20200928144957.GA90366@VM20190228-100.tbsite.net> References: <1600770804-116365-1-git-send-email-baolin.wang@linux.alibaba.com> <20200928140054.GA11500@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200928140054.GA11500@willie-the-truck> User-Agent: Mutt/1.5.21 (2010-09-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200928_105014_909790_D403EDF5 X-CRM114-Status: GOOD ( 26.31 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Baolin Wang Cc: baolin.wang7@gmail.com, catalin.marinas@arm.com, lorenzo.pieralisi@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Sep 28, 2020 at 03:00:55PM +0100, Will Deacon wrote: > [+ Lorenzo] > > On Tue, Sep 22, 2020 at 06:33:24PM +0800, Baolin Wang wrote: > > If the BIOS disabled the NUMA configuration, but did not change the > > proximity domain description in the SRAT table, so the PCI root bus > > device may get a incorrect node id by acpi_get_node(). > > How "incorrect" are we talking here? What actually goes wrong? At some > point, we have to trust what the firmware is telling us. What I mean is, if we disable the NUMA from BIOS, but we did not change the PXM for the PCI devices, so the PCI devices can still get a numa node id from acpi_get_node(). For example, we can still get the numa node id = 1 in this case from acpi_get_node(), but the numa_nodes_parsed is empty, which means the node id 1 is invalid. We should add a validation for the node id when setting the root bus node id. > > > Thus better to add a numa node validation before setting numa node > > for the PCI root bus, like pci_acpi_root_get_node() does for X86 > > architecture. > > > > Signed-off-by: Baolin Wang > > --- > > arch/arm64/kernel/pci.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c > > index 1006ed2..24fe2bd 100644 > > --- a/arch/arm64/kernel/pci.c > > +++ b/arch/arm64/kernel/pci.c > > @@ -86,9 +86,13 @@ int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge) > > struct pci_config_window *cfg = bridge->bus->sysdata; > > struct acpi_device *adev = to_acpi_device(cfg->parent); > > struct device *bus_dev = &bridge->bus->dev; > > + int node = acpi_get_node(acpi_device_handle(adev)); > > + > > + if (node != NUMA_NO_NODE && !node_online(node)) > > + node = NUMA_NO_NODE; > > Hmm. afaict, acpi_get_node() tries quite hard to return a valid node when > it gets back NUMA_NO_NODE in acpi_map_pxm_to_node(). Seems like we're > undoing all of that here, which worries me because NUMA_NO_NODE is a bit > of a loaded gun if you interpret it as a valid node. I did not treate NUMA_NO_NODE as a valid node, I just add a validation to validate if it is a valid node before setting. See my previous comments, hopes I make things clear. Thanks. > > Anyway, I defer to Lorenzo on this. > > Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel