Re: [PATCH RESEND v2 02/11] net/tap: check if name is null

[Ferruh Yigit <ferruh.yigit@amd.com>]

On 11/22/2022 3:30 PM, okaya@kernel.org wrote:
> From: Sinan Kaya <okaya@kernel.org>
> 
> In rte_pmd_tun_probe result of call to rte_vdev_device_name is
> dereferenced here and may be null.
> 
> Signed-off-by: Sinan Kaya <okaya@kernel.org>
> ---
>  drivers/net/tap/rte_eth_tap.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> index f2a6c33a19..b99439e4f2 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -2340,6 +2340,9 @@ rte_pmd_tun_probe(struct rte_vdev_device *dev)
>  	struct rte_eth_dev *eth_dev;
>  
>  	name = rte_vdev_device_name(dev);
> +	if (name == NULL)
> +		return -1;
> +
>  	params = rte_vdev_device_args(dev);
>  	memset(remote_iface, 0, RTE_ETH_NAME_MAX_LEN);
>  

Yes, technically 'rte_vdev_device_name()' can return NULL, but call
stack is like this:

`
vdev_probe_all_drivers() //in 'vdev.c'
  name = rte_vdev_device_name(dev);
  if (vdev_parse(name, &driver))
    return -1;
  ret = driver->probe(dev); //it is 'rte_pmd_tun_probe()'
`

I assume this is highlighted by a tool but in practice
'rte_vdev_device_name()' should not return NULL, and there are many
other location this check is missing.

Although it doesn't hurt, I think we can skip the check since it is
unnecessary.