From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mohammad Abdul Awal <mohammad.abdul.awal@intel.com>
Subject: Re: [PATCH 1/3] ethdev: fix null pointer checking
Date: Thu, 4 Apr 2019 09:33:05 +0100
Message-ID: <508b15c7-5ecd-4758-f985-81195620d608@intel.com>
References: <20190403160726.1231-1-mohammad.abdul.awal@intel.com>
 <1807422.QXMQecOh3y@xps> <f860c353-e1bd-67e9-ba68-b4300353a927@intel.com>
 <20190403164116.GA1344@bricha3-MOBL.ger.corp.intel.com>
 <938cd677-9563-b29e-a4ab-3c2d84c519d8@intel.com>
 <CAJFAV8wJB+th6HCOnBDDv=t_5Lp_w6eVgkCMaCJRt6NRc76xdg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Bruce Richardson <bruce.richardson@intel.com>,
 Thomas Monjalon <thomas@monjalon.net>, dev <dev@dpdk.org>,
 Andrew Rybchenko <arybchenko@solarflare.com>, dpdk stable <stable@dpdk.org>
To: David Marchand <david.marchand@redhat.com>,
 Ferruh Yigit <ferruh.yigit@intel.com>
Return-path: <dev-bounces@dpdk.org>
In-Reply-To: <CAJFAV8wJB+th6HCOnBDDv=t_5Lp_w6eVgkCMaCJRt6NRc76xdg@mail.gmail.com>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>


On 03/04/2019 18:32, David Marchand wrote:
> On Wed, Apr 3, 2019 at 6:53 PM Ferruh Yigit <ferruh.yigit@intel.com 
> <mailto:ferruh.yigit@intel.com>> wrote:
>
>     On 4/3/2019 5:41 PM, Bruce Richardson wrote:
>     > On Wed, Apr 03, 2019 at 05:35:22PM +0100, Ferruh Yigit wrote:
>     >> On 4/3/2019 5:27 PM, Thomas Monjalon wrote:
>     >>> 03/04/2019 18:07, Mohammad Abdul Awal:
>     >>>> Null value for parameter name will cause segfault for the
>     strnlen and
>     >>>> strcmp functions.
>     >>>
>     >>> I'm not sure we want such obvious checks for all APIs.  Here I
>     would
>     >>> say yes.
>     >>
>     >> These are internal functions, not APIs.  I am for verifying
>     input for
>     >> (all) APIs but not for internal functions, drivers should call
>     them and
>     >> they are in our control, if they are passing NULL we can fix
>     them :)
>     >>
>     > True, but if these are control path or init time code paths
>     rather than
>     > data path APIs, I don't see the harm in putting in the checks.
>
>     No harm from performance point of view, agree, but also looks
>     unnecessary to me.
>
>
> +1
> All the more when you see the following patches that adds input checks 
> in the faulty/too naive drivers.
>
>
> -- 
> David Marchand


Self-NACK to the patch considering the discussion above.