From patchwork Mon Jul 9 18:20:23 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bjorn Helgaas X-Patchwork-Id: 169912 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 819B32C0200 for ; Tue, 10 Jul 2012 04:20:51 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752700Ab2GISU1 (ORCPT ); Mon, 9 Jul 2012 14:20:27 -0400 Received: from mail-vb0-f74.google.com ([209.85.212.74]:64763 "EHLO mail-vb0-f74.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752542Ab2GISUY (ORCPT ); Mon, 9 Jul 2012 14:20:24 -0400 Received: by mail-vb0-f74.google.com with SMTP id l22so1218492vbn.1 for ; Mon, 09 Jul 2012 11:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:to:from:cc:date:message-id:in-reply-to:references :user-agent:mime-version:content-type:content-transfer-encoding; bh=R6bQLTDrPhBq6JLt4xIhAbT676L9Lrbjb1U5fwiF/IA=; b=UtdT9A4XeTnxSCTOJgMjS3mTJtgi7oK6PppY0J+4SOKWZYdMISVZOoo0v+xg++jRug Tpw5D199IeGj0GdMpwpH0uq3PokIrRc/JEdTC/4Kg6WKcGpk0UgEOArj/ZsIErCnW8c9 9FqWFSghKcC9D2/VAOY2xotigDb9upIBq8arKqY4vS2FamIMzYirfwGujD7q+oVsVA3j gB4BgGbXQ27nGkIA4BkVYwxDcU3aAKItPFwTsh+6fs0j+aLW40jelLPc+esPX6JAfEna Fp0q7qyj5W8cMhWrGoeygA13/reVjDH6tJw+YHohjMc2Muy8CXPPitExovAaTUvEr7tE N5bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:to:from:cc:date:message-id:in-reply-to:references :user-agent:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=R6bQLTDrPhBq6JLt4xIhAbT676L9Lrbjb1U5fwiF/IA=; b=Ny37CZvp5EQgXzpVHfKGq+NuvRHrAHiJPSElcmxX95jrgESP78IEuyomc9bCXUG3RP 77WyFoMDnzuxmErP6VV9D76uqBKimJIkUE53w16aJRk0t/VObGRGjUYK5WdrtCvWRPCd CcSWTU+RTSriKRFRhlwAihwxqQwnU2AnOpDxwabzpD2GBjKKkiFRLmAuGdQwYEUCeGEG Rb4w91pQPeMwY3KWHs7Rv/Pn/MsnxOiNr7H4ucS8RiaPskXSVgVjz1CE55//YrTIm+k4 JJKnH3AkThlU6m3Wz5q45PNl9e86QK0omtkPjGfsD5fV51AII9LLDjqwEem1zz0HbSnR hf0w== Received: by 10.236.83.111 with SMTP id p75mr63283515yhe.5.1341858023878; Mon, 09 Jul 2012 11:20:23 -0700 (PDT) Received: by 10.236.83.111 with SMTP id p75mr63283502yhe.5.1341858023803; Mon, 09 Jul 2012 11:20:23 -0700 (PDT) Received: from wpzn3.hot.corp.google.com (216-239-44-65.google.com [216.239.44.65]) by gmr-mx.google.com with ESMTPS id n15si3560168anq.2.2012.07.09.11.20.23 (version=TLSv1/SSLv3 cipher=AES128-SHA); Mon, 09 Jul 2012 11:20:23 -0700 (PDT) Received: from bhelgaas.mtv.corp.google.com (bhelgaas.mtv.corp.google.com [172.18.96.155]) by wpzn3.hot.corp.google.com (Postfix) with ESMTP id ADE98100047; Mon, 9 Jul 2012 11:20:23 -0700 (PDT) Received: from bhelgaas.mtv.corp.google.com (unknown [IPv6:::1]) by bhelgaas.mtv.corp.google.com (Postfix) with ESMTP id 64C56180156; Mon, 9 Jul 2012 11:20:23 -0700 (PDT) Subject: [PATCH 2/2] PCI: disable MEM decoding while updating 64-bit MEM BARs To: linux-pci@vger.kernel.org From: Bjorn Helgaas Cc: Jacob Pan , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Jesse Barnes , Ivan Kokshaysky , Matthew Wilcox , Robert Hancock Date: Mon, 09 Jul 2012 12:20:23 -0600 Message-ID: <20120709182023.18165.95880.stgit@bhelgaas.mtv.corp.google.com> In-Reply-To: <20120709181745.18165.93914.stgit@bhelgaas.mtv.corp.google.com> References: <20120709181745.18165.93914.stgit@bhelgaas.mtv.corp.google.com> User-Agent: StGit/0.15 MIME-Version: 1.0 X-Gm-Message-State: ALoCoQkitJVVvLk/Nxj4GAaIpbAVvKrFLJg7nTZuGh7XcFfWCip89rSF57TX6Hq3OGyPvQDlxboSZ2CuRC10yfJCU4nZGZrKeVffqJjaA3lsv/HSM8D6o1QS8UcKfqIVGY4yhMcGX10eO4d/n2SpSup0wqzI4vW/2hGEBVL/DICvASgGTgAAAEcszW1Xul8n8IuQowR70eWy Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org When we update 64-bit BARs, we have to perform two config writes. Between the writes, the half-written BAR value could match a MEM access intended for another device. This could result in corruption of this device (for writes) or an unexpected response machine check (for reads). To prevent this, disable MEM decoding while updating such BARs. This uses the same safety test as 253d2e5498, which disables both MEM and IO while sizing BARs, namely, we don't disable decoding for host bridge devices. Signed-off-by: Bjorn Helgaas --- drivers/pci/setup-res.c | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c index eea85da..1a0e60e 100644 --- a/drivers/pci/setup-res.c +++ b/drivers/pci/setup-res.c @@ -30,6 +30,8 @@ void pci_update_resource(struct pci_dev *dev, int resno) { struct pci_bus_region region; + bool disable; + u16 cmd; u32 new, check, mask; int reg; enum pci_bar_type type; @@ -67,6 +69,18 @@ void pci_update_resource(struct pci_dev *dev, int resno) new |= PCI_ROM_ADDRESS_ENABLE; } + /* + * We can't update a 64-bit BAR atomically, so when possible, + * disable decoding so that a half-updated BAR won't conflict + * with another device. + */ + disable = (res->flags & IORESOURCE_MEM_64) && !dev->mmio_always_on; + if (disable) { + pci_read_config_word(dev, PCI_COMMAND, &cmd); + pci_write_config_word(dev, PCI_COMMAND, + cmd & ~PCI_COMMAND_MEMORY); + } + pci_write_config_dword(dev, reg, new); pci_read_config_dword(dev, reg, &check); @@ -84,6 +98,10 @@ void pci_update_resource(struct pci_dev *dev, int resno) "(high %#08x != %#08x)\n", resno, new, check); } } + + if (disable) + pci_write_config_word(dev, PCI_COMMAND, cmd); + res->flags &= ~IORESOURCE_UNSET; dev_dbg(&dev->dev, "BAR %d: set to %pR (PCI address [%#llx-%#llx])\n", resno, res, (unsigned long long)region.start,