[dpdk-dev] [PATCH v7 7/7] igb_uio: fix uio release issue when hot unplug
Jeff Guo
jia.guo at intel.com
Tue Jul 10 10:28:33 CEST 2018
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.guo at 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.
More information about the dev
mailing list