Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp52802img; Wed, 20 Mar 2019 13:53:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqyR8H1ydEZNEjxDN7CbHgOgUuJZ/YG7UXD4Y64tS/8MB9Ss8I5oC5b8pNlxch1HZkrko4uY X-Received: by 2002:a62:1249:: with SMTP id a70mr9733911pfj.160.1553115237267; Wed, 20 Mar 2019 13:53:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553115237; cv=none; d=google.com; s=arc-20160816; b=zMziqol9xBoSa+XmAGLHk30mjAo+kIMTzafAsIVSui1AXbMkmkdWOoBSdYTazKooQc fVOmaKG3m7MrlngQ2M2St6EO7a4pyP08eUwUYb3uPpSaWlivDLnV7uqSsOivWjeONIcg RK6aZVGRUCdONzcb7tMxJofYjr1mzVpGEJ7kRqArlwpuwnB2BphVLwVhYj0lyb13uy14 eJHtXOB9Mn9XN+h/P1I+inBzGRBqprPGKmsYCy7FpC7TFVurvEpBC8yBUxyemHoO8C3e GeE8Brytdq/69bwYwqzhQ0iAO+ykhs/vxdUcreWmKxp7O5y5zEZiPay/4txac/zNhx1o ABcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=WFhdXhuKiLKp8xO/DEOqD7u1KSzqXiN44+PCDWUwU6E=; b=FLEblkMlI84jkWXrnONkihcUdXstW/O7sZ2NgiXi1SEgSIUTWNOdTyeWHl2QeMtNz/ v9EMy7ns+rFj0/fLKr5UFiWXJHr2nLcSDm2UoBX4H+GFJHQ59qyFAJF7Z3gKB7eQamg6 umCNPEhfufcuat/1z0eT+Itr9ugPueXIbvdAJ57FTXPwOlmwDP8zUe1cJ8yiqQmJirBG Zizo/vCUECsSf2qzbe9/kM4fwD5Hd1r3a9eWGjSEpQhzjcGlKsWa6v7z0tjGTNDd+5A7 75XUbE/blho85AhxGvh1i7O7+uRom0KHGgfG8US/j8yk6qOI8SXRgchvgFAFIdxpe9IT baqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=lyDrQ2lf; 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 k127si2490912pgc.124.2019.03.20.13.53.42; Wed, 20 Mar 2019 13:53:57 -0700 (PDT) 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=lyDrQ2lf; 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 S1727414AbfCTUwh (ORCPT + 99 others); Wed, 20 Mar 2019 16:52:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:51274 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726006AbfCTUwh (ORCPT ); Wed, 20 Mar 2019 16:52:37 -0400 Received: from localhost (unknown [69.71.4.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E3D69218C3; Wed, 20 Mar 2019 20:52:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1553115155; bh=KhM59fq0xMcxfrPWegt3eJ/Pj0d60Y1W4KnA/CcsvYA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lyDrQ2lfJ8reyDeVFxG2UYbgulcfBgBQjpYvufZ2RV6cy+pjwJbUMsFoNTdVjApwN jDY9JaM8KVc79RTb5fJL8rQzvLsszooOxN0bvFh1eOrevnb3ePnut9xH7zaBmP/Y0G 3fhjWZwYWmNEQFSpCIKQYz1zDaPa8Ncz0j6sPHVE= Date: Wed, 20 Mar 2019 15:52:33 -0500 From: Bjorn Helgaas To: Alexandru Gagniuc Cc: austin_bolen@dell.com, alex_gagniuc@dellteam.com, keith.busch@intel.com, Shyam_Iyer@Dell.com, lukas@wunner.de, okaya@kernel.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Jon Derrick , Jens Axboe , Christoph Hellwig , Sagi Grimberg , linux-nvme@lists.infradead.org, Linus Torvalds , Greg Kroah-Hartman , Oliver O'Halloran Subject: Re: [PATCH v3] PCI/MSI: Don't touch MSI bits when the PCI device is disconnected Message-ID: <20190320205233.GE251185@google.com> References: <20190222194808.15962-1-mr.nuke.me@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190222194808.15962-1-mr.nuke.me@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [+cc Jon, Jens, Christoph, Sagi, Linus, linux-nvme from related discussion] [+cc Greg, Oliver, who responded to v2 of this patch] On Fri, Feb 22, 2019 at 01:48:06PM -0600, Alexandru Gagniuc wrote: > A SURPRISE removal of a hotplug PCIe device, caused by a Link Down > event will execute an orderly removal of the driver, which normally > includes releasing the IRQs with pci_free_irq(_vectors): > > * SURPRISE removal event causes Link Down > * pciehp_disable_slot() > * pci_device_remove() > * driver->remove() > * pci_free_irq(_vectors)() > * irq_chip->irq_mask() > * pci_msi_mask_irq() > > Eventually, msi_set_mask_bit() will attempt to do MMIO over the dead > link, usually resulting in an Unsupported Request error. This can > confuse the firmware on FFS machines, and lead to a system crash. > > Since the channel will have been marked "pci_channel_io_perm_failure" > by the hotplug thread, we know we should avoid sending blind IO to a > dead link. > When the device is disconnected, bail out of MSI teardown. > > If device removal and Link Down are independent events, there exists a > race condition when the Link Down event occurs right after the > pci_dev_is_disconnected() check. This is outside the scope of this patch. > > Signed-off-by: Alexandru Gagniuc I had actually applied this to pci/msi with the intent of merging it for v5.1, but by coincidence I noticed [1], where Jon was basically solving another piece of the same problem, this time in nvme-pci. AFAICT, the consensus there was that it would be better to find some sort of platform solution instead of dealing with it in individual drivers. The PCI core isn't really a driver, but I think the same argument applies to it: if we had a better way to recover from readl() errors, that way would work equally well in nvme-pci and the PCI core. It sounds like the problem has two parts: the PCI core part and the individual driver part. Solving only the first (eg, with this patch) isn't enough by itself, and solving the second via some platform solution would also solve the first. If that's the case, I don't think it's worth applying this one, but please correct me if I'm wrong. Bjorn [1] https://lore.kernel.org/lkml/20190222010502.2434-1-jonathan.derrick@intel.com/T/#u > --- > Changes since v2: > * Updated commit message > > drivers/pci/msi.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c > index 4c0b47867258..6b6541ab264f 100644 > --- a/drivers/pci/msi.c > +++ b/drivers/pci/msi.c > @@ -227,6 +227,9 @@ static void msi_set_mask_bit(struct irq_data *data, u32 flag) > { > struct msi_desc *desc = irq_data_get_msi_desc(data); > > + if (pci_dev_is_disconnected(msi_desc_to_pci_dev(desc))) > + return; > + > if (desc->msi_attrib.is_msix) { > msix_mask_irq(desc, flag); > readl(desc->mask_base); /* Flush write to device */ > -- > 2.19.2 >