diff options
author | 2018-05-02 17:26:28 -0300 | |
---|---|---|
committer | 2018-05-17 09:00:54 -0700 | |
commit | b212d815e77c72be921979119c715166cc8987b1 (patch) | |
tree | 803056590e26254b65911a936b33920e4427e489 /include/linux/tcp.h | |
parent | ixgbe: cleanup sparse warnings (diff) | |
download | wireguard-linux-b212d815e77c72be921979119c715166cc8987b1.tar.xz wireguard-linux-b212d815e77c72be921979119c715166cc8987b1.zip |
ixgbe/ixgbevf: Free IRQ when PCI error recovery removes the device
Since commit f7f37e7ff2b9 ("ixgbe: handle close/suspend race with
netif_device_detach/present") ixgbe_close_suspend is called, from
ixgbe_close, only if the device is present, i.e. if it isn't detached.
That exposed a situation where IRQs weren't freed if a PCI error
recovery system opts to remove the device. For such case the pci channel
state is set to pci_channel_io_perm_failure and ixgbe_io_error_detected
was returning PCI_ERS_RESULT_DISCONNECT before calling
ixgbe_close_suspend consequentially not freeing IRQ and crashing when
the remove handler calls pci_disable_device, hitting a BUG_ON at
free_msi_irqs, which asserts that there is no non-free IRQ associated
with the device to be removed:
BUG_ON(irq_has_action(entry->irq + i));
The issue is fixed by calling the ixgbe_close_suspend before evaluate
the pci channel state.
Reported-by: Naresh Bannoth <nbannoth@in.ibm.com>
Reported-by: Abdul Haleem <abdhalee@in.ibm.com>
Signed-off-by: Mauro S M Rodrigues <maurosr@linux.vnet.ibm.com>
Reviewed-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Diffstat (limited to 'include/linux/tcp.h')
0 files changed, 0 insertions, 0 deletions