[dpdk-dev] [PATCH 2/3] net/virtio: fix null pointer checking

[Mohammad Abdul Awal]

On 04/04/2019 07:22, Tiwei Bie wrote:
> On Wed, Apr 03, 2019 at 05:08:11PM +0100, Mohammad Abdul Awal wrote:
>> Null value of device name should return error without further processing.
>>
>> Fixes: 1c8489da56 ("net/virtio-user: fix multi-process support")
>>
>> Signed-off-by: Mohammad Abdul Awal <mohammad.abdul.awal at intel.com>
>> ---
>>   drivers/net/virtio/virtio_user_ethdev.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/net/virtio/virtio_user_ethdev.c b/drivers/net/virtio/virtio_user_ethdev.c
>> index 129c2b9ef..cefc6da66 100644
>> --- a/drivers/net/virtio/virtio_user_ethdev.c
>> +++ b/drivers/net/virtio/virtio_user_ethdev.c
>> @@ -516,6 +516,10 @@ virtio_user_pmd_probe(struct rte_vdev_device *dev)
>>   
>>   	if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
>>   		const char *name = rte_vdev_device_name(dev);
>> +		if (name == NULL) {
>> +			RTE_LOG(ERR, PMD, "Device name is NULL\n");
>> +			return -1;
>> +		}
> It seems there is a lot of code in DPDK doesn't do the null
> pointer check in this case. Is it worth fixing them as well?
> Or should vdev bus guarantee that it won't ask driver to probe
> a device without device name (without a device name, vdev bus
> shouldn't be able to find a driver to probe actually)?
>
> Thanks,
> Tiwei

In fact, the dev->name is already checked for NULL in find_vdev() 
function of duing the vdev bus scanning time.

Hence, self-NACK for the patch.


>
>>   		eth_dev = rte_eth_dev_attach_secondary(name);
>>   		if (!eth_dev) {
>>   			RTE_LOG(ERR, PMD, "Failed to probe %s\n", name);
>> -- 
>> 2.17.1
>>