I found the same issue: https://patchwork.ozlabs.org/patch/989272/ Tested-by: Jon Derrick <jonathan.derrick@xxxxxxxxx> On Mon, 2018-11-05 at 18:32 -0600, Alex G. wrote: > ping > > On 09/18/2018 05:15 PM, Alexandru Gagniuc wrote: > > When a PCI device is gone, we don't want to send IO to it if we can > > avoid it. We expose functionality via the irq_chip structure. As > > users of that structure may not know about the underlying PCI > > device, > > it's our responsibility to guard against removed devices. > > > > .irq_write_msi_msg() is already guarded inside > > __pci_write_msi_msg(). > > .irq_mask/unmask() are not. Guard them for completeness. > > > > For example, surprise removal of a PCIe device triggers teardown. > > This > > touches the irq_chips ops some point to disable the interrupts. I/O > > generated here can crash the system on firmware-first machines. > > Not triggering the IO in the first place greatly reduces the > > possibility of the problem occurring. > > > > Signed-off-by: Alexandru Gagniuc <mr.nuke.me@xxxxxxxxx> > > --- > > drivers/pci/msi.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c > > index f2ef896464b3..f31058fd2260 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 */ > >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
