[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