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.a...@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
