[V2,1/6] bus/pci: fix a segfault when call callback

  After the driver probe is executed, the callback in application will
be called. The callback in application may call some APIs which access the
rte_pci_driver::driver by the device::driver pointer to get driver
information. If the rte_pci_device::device::driver pointer isn't pointed to
rte_pci_driver::driver in rte_pci_probe_one_driver, a segfault will occur.
For example, when ethdev driver probe completes, the callback in
application call rte_eth_dev_info_get which use dev->device->driver->name.
So rte_pci_device::device::driver should point to rte_pci_driver::driver
before executing the driver probe.

Fixes: c752998b5e2e ("pci: introduce library and driver")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 drivers/bus/pci/pci_common.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
  

15/09/2022 14:45, Huisong Li:
> After the driver probe is executed, the callback in application will
> be called. The callback in application may call some APIs which access the
> rte_pci_driver::driver by the device::driver pointer to get driver
> information. If the rte_pci_device::device::driver pointer isn't pointed to
> rte_pci_driver::driver in rte_pci_probe_one_driver, a segfault will occur.
> For example, when ethdev driver probe completes, the callback in
> application call rte_eth_dev_info_get which use dev->device->driver->name.
> So rte_pci_device::device::driver should point to rte_pci_driver::driver
> before executing the driver probe.
> 
> Fixes: c752998b5e2e ("pci: introduce library and driver")
> Cc: stable@dpdk.org

To be more precise, it is reverting
391797f04208 ("drivers/bus: move driver assignment to end of probing")

dev->device.driver is used by rte_dev_is_probed():

int
rte_dev_is_probed(const struct rte_device *dev)
{
    /* The field driver should be set only when the probe is successful. */
    return dev->driver != NULL;
}

And the field comment is clear in rte_device:

const struct rte_driver *driver; /**< Driver assigned after probing */

That's why I am not enthusiastic about setting this pointer before probing.

I understand it is more convenient to use this pointer
in a probing callback.
We need to check it is not breaking rte_dev_is_probed() usage.
It may be OK if there is no parallel probing,
and rte_dev_is_probed() is not called inside probing.

At the very minimum, we need to update some comments in the code,
to mention that the pointer is set before probing,
and reset if probing failed.
  

Hi Thomas,

I missed this e-mail, I'm sorry for late reply.

在 2022/10/11 3:49, Thomas Monjalon 写道:
> 15/09/2022 14:45, Huisong Li:
>> After the driver probe is executed, the callback in application will
>> be called. The callback in application may call some APIs which access the
>> rte_pci_driver::driver by the device::driver pointer to get driver
>> information. If the rte_pci_device::device::driver pointer isn't pointed to
>> rte_pci_driver::driver in rte_pci_probe_one_driver, a segfault will occur.
>> For example, when ethdev driver probe completes, the callback in
>> application call rte_eth_dev_info_get which use dev->device->driver->name.
>> So rte_pci_device::device::driver should point to rte_pci_driver::driver
>> before executing the driver probe.
>>
>> Fixes: c752998b5e2e ("pci: introduce library and driver")
>> Cc: stable@dpdk.org
> To be more precise, it is reverting
> 391797f04208 ("drivers/bus: move driver assignment to end of probing")
>
> dev->device.driver is used by rte_dev_is_probed():
>
> int
> rte_dev_is_probed(const struct rte_device *dev)
> {
>      /* The field driver should be set only when the probe is successful. */
>      return dev->driver != NULL;
> }
>
> And the field comment is clear in rte_device:
>
> const struct rte_driver *driver; /**< Driver assigned after probing */
>
> That's why I am not enthusiastic about setting this pointer before probing.
+1
>
> I understand it is more convenient to use this pointer
> in a probing callback.
> We need to check it is not breaking rte_dev_is_probed() usage.
> It may be OK if there is no parallel probing,
> and rte_dev_is_probed() is not called inside probing.
 From all the places where it's used, first of all, it is a internal 
interface
and only used when scan device on bus, remove device and hotplug device.

In process of scanning or probing device, the core code checks whether the
device is already probed by calling rte_dev_is_probed(). So I think it is ok
for parallel probing(if exist) to set dev->device.driver before probing 
successful.
The Concurrency between probing and removing should not be possible. The 
application
removes a device after device probing successful.

Currently, rte_dev_is_probed() isn't called inside probing.
>
> At the very minimum, we need to update some comments in the code,
> to mention that the pointer is set before probing,
> and reset if probing failed.
If it is ok for you, I will update some comments and add this 
modification to
other bus type in next version.
>
>
> .