hi, stephen
Thanks for your review.
On 7/10/2018 6:44 AM, Stephen Hemminger wrote:
On Mon, 9 Jul 2018 20:01:06 +0800
Jeff Guo <jia....@intel.com> wrote:
@@ -195,12 +205,22 @@ igbuio_pci_irqhandler(int irq, void *dev_id)
{
struct rte_uio_pci_dev *udev = (struct rte_uio_pci_dev *)dev_id;
struct uio_info *info = &udev->info;
+ struct pci_dev *pdev = udev->pdev;
/* Legacy mode need to mask in hardware */
if (udev->mode == RTE_INTR_MODE_LEGACY &&
!pci_check_and_mask_intx(udev->pdev))
return IRQ_NONE;
+ mutex_lock(&udev->lock);
+ /* check the uevent of the kobj */
+ if ((&pdev->dev.kobj)->state_remove_uevent_sent == 1) {
+ dev_notice(&pdev->dev, "device:%s, sent remove uevent!\n",
+ (&pdev->dev.kobj)->name);
+ udev->state = RTE_UDEV_UNPLUG;
+ }
+ mutex_unlock(&udev->lock);
Did you run with lockdep?
I don't think you can safely acquire a mutex (would sleep) in IRQ context.
I think lockdep could do me a favor about that, but i think only the
uio remove function will check the unplug status, so i think i could let
this
check in the uio remove function, no need to let it in irq handler
anymore, since like what you said acquire a mutex in IRQ context is no safe.
