linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Alexandru Gagniuc <mr.nuke.me@gmail.com>
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 <jonathan.derrick@intel.com>,
	Jens Axboe <axboe@fb.com>, Christoph Hellwig <hch@lst.de>,
	Sagi Grimberg <sagi@grimberg.me>,
	linux-nvme@lists.infradead.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Oliver O'Halloran <oohall@gmail.com>
Subject: Re: [PATCH v3] PCI/MSI: Don't touch MSI bits when the PCI device is disconnected
Date: Wed, 20 Mar 2019 15:52:33 -0500	[thread overview]
Message-ID: <20190320205233.GE251185@google.com> (raw)
In-Reply-To: <20190222194808.15962-1-mr.nuke.me@gmail.com>

[+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 <mr.nuke.me@gmail.com>

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
> 

  reply	other threads:[~2019-03-20 20:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-22 19:48 [PATCH v3] PCI/MSI: Don't touch MSI bits when the PCI device is disconnected Alexandru Gagniuc
2019-03-20 20:52 ` Bjorn Helgaas [this message]
2019-03-20 21:44   ` Linus Torvalds
2019-03-21  1:27     ` Alex G
2019-03-21  4:57       ` Oliver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190320205233.GE251185@google.com \
    --to=helgaas@kernel.org \
    --cc=Shyam_Iyer@Dell.com \
    --cc=alex_gagniuc@dellteam.com \
    --cc=austin_bolen@dell.com \
    --cc=axboe@fb.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=jonathan.derrick@intel.com \
    --cc=keith.busch@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mr.nuke.me@gmail.com \
    --cc=okaya@kernel.org \
    --cc=oohall@gmail.com \
    --cc=sagi@grimberg.me \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).