[dpdk-dev] [PATCH v8 7/7] igb_uio: fix uio release issue for hotplug

Jeff Guo jia.guo at intel.com
Wed Jul 11 05:10:44 CEST 2018



On 7/11/2018 5:48 AM, Stephen Hemminger wrote:
> On Tue, 10 Jul 2018 19:03:27 +0800
> Jeff Guo <jia.guo at intel.com> wrote:
>
>>   
>> +/* uio pci device state */
>> +enum rte_udev_state {
>> +	RTE_UDEV_PROBED,
>> +	RTE_UDEV_OPENNED,
>> +	RTE_UDEV_RELEASED,
>> +	RTE_UDEV_REMOVED,
>> +};
>> +
> The states here are a little confusing. especially since pci_release
> seems to take different actions based on the state. And there is nothing
> preventing races between unexpected removal (PCI), and removing the
> device from being used by igb_uio.

The states here just manage in igb uio, and only restore the status of 
igb uio.
And only the RTE_UDEV_REMOVED that the key status might be a highlight 
and process, it is means pci have been removed, then directly come to 
igb uio remove without go igb uio release at first,
the status is for hotplug out, need to do specific process. It will no 
affect the normal process, and for normal igb uio remove, udev be 
release, no any status need to restore.

> Would it be possible to only use state variable from the kernel PCI
> layer where the value is consistent?

The state which i only care here is hot remove state, i check that 
kobj->state_remove_uevent_sent could be use in igb uio,
except that still can not find a specific state of kernel pci to 
identify it. If we can find it, it should be best.
what's other comment from guys?

> Also there is refcounting in PCI layer (and locking). Could that
> be used instead?

It might be, but if state is enough here we might not considerate to use 
it. If i am missing anything, let me know.




More information about the dev mailing list