Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1946436ybv; Fri, 14 Feb 2020 08:40:48 -0800 (PST) X-Google-Smtp-Source: APXvYqxHvjfJBIj40Jgs/U4K5sSzMoRbI+yBtIvGpb+r/aXjwljfbPg5w02PRS8qL3jIONoWuR9D X-Received: by 2002:a05:6830:2111:: with SMTP id i17mr2864823otc.24.1581698448147; Fri, 14 Feb 2020 08:40:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581698448; cv=none; d=google.com; s=arc-20160816; b=gQcGjqUO/8q9rqCfjYpjSke+Pa/3mxFA1FCHLG9VjR50JTKAIYZMR//If15biZQHwO Nf40rgDGPLo1djwrnp6FUCBzTcgSzcKF7InGP0i31B1E4jBqmMz/zwVho2mkrqSzD1TP YctPXgt9tiKKzAXJwHxNDeOCM8S1sYniqqtW+WbRqTZoiF741DEuCNJr+0hoAoARFOG1 SRcy2hFCUOPnMN9Fibw1QEUj1eaEGI3t9vuDi9mbapV9kuAiIt+tTpIMxGhPLi82qNEc o1aBcbH2ct8EqEHk4wGt8yuo1SB1ycznMX1RaY5WcvwgyTkRb1sx0VXyMxUZ4ypsBWto 4qlA== 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 :dkim-signature; bh=P29iChp6yEfnoKCf/7iUqYJZBu3hhIP72mbDDmFKATM=; b=hXOLBAZjKnK4HfOLDQf3LsGZkc0hqDUxbigrkfnzJ1AJOEMUs+R9YJqiTVOksU1CqK We/x5FCLS6Ck/FCbcue7bvzvuwhRD7Cs1XKkEkEh7cUsoP8olyIAUPDotncD1X7gr+y+ QtPLLlAwVWctAMk/AUA7WulJGjFAfEsrDUL01ZlZcOhje/y3GJFlQwiyoLKUG2fPPCJe jw1646vh2ohPpWytzG77FRntssHPGrpBOxIJllPIC/ycQl7utWqvkfDZkCvpZUceMMzO y8/6KJzddhWx+cPvBtLfIaw3ZBXSury/R119tMAmK2r/HEVZhfgBCvKtLO2KyBYqUPoZ jBPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=OVLC7nOI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z7si3272396oth.181.2020.02.14.08.40.36; Fri, 14 Feb 2020 08:40:48 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=OVLC7nOI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2393891AbgBNQjE (ORCPT + 99 others); Fri, 14 Feb 2020 11:39:04 -0500 Received: from mail.kernel.org ([198.145.29.99]:59470 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405585AbgBNQXS (ORCPT ); Fri, 14 Feb 2020 11:23:18 -0500 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E926A24776; Fri, 14 Feb 2020 16:23:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581697397; bh=dsqEi709l+qenfWhaHd3mIIG/QwcXpRGZyNSwjjHc4Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OVLC7nOIpQkfTk5d8oBr536SqcTcVnlupXIN4C7xLdgtAZPWFtOTZFyPnDZ+gtYnS LqrJi9EjqbMnx8ptmpxRp+mFyRPWLzi1ddQdlQkbm9DFQRS6tzsxcJs3MP2g/8W5a8 bDe9fj9YLOVJevmEXXHJM0o+vI8PCNhWLHsGcdEE= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Logan Gunthorpe , Kit Chow , Bjorn Helgaas , Sasha Levin , linux-pci@vger.kernel.org Subject: [PATCH AUTOSEL 4.9 091/141] PCI: Don't disable bridge BARs when assigning bus resources Date: Fri, 14 Feb 2020 11:20:31 -0500 Message-Id: <20200214162122.19794-91-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200214162122.19794-1-sashal@kernel.org> References: <20200214162122.19794-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Logan Gunthorpe [ Upstream commit 9db8dc6d0785225c42a37be7b44d1b07b31b8957 ] Some PCI bridges implement BARs in addition to bridge windows. For example, here's a PLX switch: 04:00.0 PCI bridge: PLX Technology, Inc. PEX 8724 24-Lane, 6-Port PCI Express Gen 3 (8 GT/s) Switch, 19 x 19mm FCBGA (rev ca) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 30, NUMA node 0 Memory at 90a00000 (32-bit, non-prefetchable) [size=256K] Bus: primary=04, secondary=05, subordinate=0a, sec-latency=0 I/O behind bridge: 00002000-00003fff Memory behind bridge: 90000000-909fffff Prefetchable memory behind bridge: 0000380000800000-0000380000bfffff Previously, when the kernel assigned resource addresses (with the pci=realloc command line parameter, for example) it could clear the struct resource corresponding to the BAR. When this happened, lspci would report this BAR as "ignored": Region 0: Memory at (32-bit, non-prefetchable) [size=256K] This is because the kernel reports a zero start address and zero flags in the corresponding sysfs resource file and in /proc/bus/pci/devices. Investigation with 'lspci -x', however, shows the BIOS-assigned address will still be programmed in the device's BAR registers. It's clearly a bug that the kernel lost track of the BAR value, but in most cases, this still won't result in a visible issue because nothing uses the memory, so nothing is affected. However, when an IOMMU is in use, it will not reserve this space in the IOVA because the kernel no longer thinks the range is valid. (See dmar_init_reserved_ranges() for the Intel implementation of this.) Without the proper reserved range, a DMA mapping may allocate an IOVA that matches a bridge BAR, which results in DMA accesses going to the BAR instead of the intended RAM. The problem was in pci_assign_unassigned_root_bus_resources(). When any resource from a bridge device fails to get assigned, the code set the resource's flags to zero. This makes sense for bridge windows, as they will be re-enabled later, but for regular BARs, it makes the kernel permanently lose track of the fact that they decode address space. Change pci_assign_unassigned_root_bus_resources() and pci_assign_unassigned_bridge_resources() so they only clear "res->flags" for bridge *windows*, not bridge BARs. Fixes: da7822e5ad71 ("PCI: update bridge resources to get more big ranges when allocating space (again)") Link: https://lore.kernel.org/r/20200108213208.4612-1-logang@deltatee.com [bhelgaas: commit log, check for pci_is_bridge()] Reported-by: Kit Chow Signed-off-by: Logan Gunthorpe Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin --- drivers/pci/setup-bus.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index f30ca75b5b6c7..e631636a0aa50 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -1833,12 +1833,18 @@ void pci_assign_unassigned_root_bus_resources(struct pci_bus *bus) /* restore size and flags */ list_for_each_entry(fail_res, &fail_head, list) { struct resource *res = fail_res->res; + int idx; res->start = fail_res->start; res->end = fail_res->end; res->flags = fail_res->flags; - if (fail_res->dev->subordinate) - res->flags = 0; + + if (pci_is_bridge(fail_res->dev)) { + idx = res - &fail_res->dev->resource[0]; + if (idx >= PCI_BRIDGE_RESOURCES && + idx <= PCI_BRIDGE_RESOURCE_END) + res->flags = 0; + } } free_list(&fail_head); @@ -1904,12 +1910,18 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge) /* restore size and flags */ list_for_each_entry(fail_res, &fail_head, list) { struct resource *res = fail_res->res; + int idx; res->start = fail_res->start; res->end = fail_res->end; res->flags = fail_res->flags; - if (fail_res->dev->subordinate) - res->flags = 0; + + if (pci_is_bridge(fail_res->dev)) { + idx = res - &fail_res->dev->resource[0]; + if (idx >= PCI_BRIDGE_RESOURCES && + idx <= PCI_BRIDGE_RESOURCE_END) + res->flags = 0; + } } free_list(&fail_head); -- 2.20.1