From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 8A64C1B134 for ; Thu, 4 Apr 2019 12:22:48 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2019 03:22:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,308,1549958400"; d="scan'208";a="313075789" Received: from awalabdu-mobl.ger.corp.intel.com (HELO [163.33.176.61]) ([163.33.176.61]) by orsmga005.jf.intel.com with ESMTP; 04 Apr 2019 03:22:44 -0700 To: Tiwei Bie Cc: dev@dpdk.org, maxime.coquelin@redhat.com, zhihong.wang@intel.com References: <20190403160811.1282-1-mohammad.abdul.awal@intel.com> <20190404062235.GA8201@dpdk-tbie.sh.intel.com> From: Mohammad Abdul Awal Message-ID: <14479e11-3f81-64ae-2a48-5ec49fdd83b5@intel.com> Date: Thu, 4 Apr 2019 11:22:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190404062235.GA8201@dpdk-tbie.sh.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH 2/3] net/virtio: fix null pointer checking X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 10:22:49 -0000 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 >> --- >> 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 >> From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 5A444A0679 for ; Thu, 4 Apr 2019 12:22:51 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 230611B137; Thu, 4 Apr 2019 12:22:50 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 8A64C1B134 for ; Thu, 4 Apr 2019 12:22:48 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2019 03:22:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,308,1549958400"; d="scan'208";a="313075789" Received: from awalabdu-mobl.ger.corp.intel.com (HELO [163.33.176.61]) ([163.33.176.61]) by orsmga005.jf.intel.com with ESMTP; 04 Apr 2019 03:22:44 -0700 To: Tiwei Bie Cc: dev@dpdk.org, maxime.coquelin@redhat.com, zhihong.wang@intel.com References: <20190403160811.1282-1-mohammad.abdul.awal@intel.com> <20190404062235.GA8201@dpdk-tbie.sh.intel.com> From: Mohammad Abdul Awal Message-ID: <14479e11-3f81-64ae-2a48-5ec49fdd83b5@intel.com> Date: Thu, 4 Apr 2019 11:22:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190404062235.GA8201@dpdk-tbie.sh.intel.com> Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH 2/3] net/virtio: fix null pointer checking X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190404102243.s8ky7XesLvhVtUEfIFPJht2psUCLgZ-51jblvkMwUWw@z> 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 >> --- >> 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 >>