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 27085A0679 for ; Wed, 3 Apr 2019 18:41:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1A9011B4E5; Wed, 3 Apr 2019 18:41:24 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id CD22D1B4E5; Wed, 3 Apr 2019 18:41:21 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Apr 2019 09:41:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,305,1549958400"; d="scan'208";a="146305373" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.7.174]) by FMSMGA003.fm.intel.com with SMTP; 03 Apr 2019 09:41:18 -0700 Received: by (sSMTP sendmail emulation); Wed, 03 Apr 2019 17:41:17 +0100 Date: Wed, 3 Apr 2019 17:41:17 +0100 From: Bruce Richardson To: Ferruh Yigit Cc: Thomas Monjalon , Mohammad Abdul Awal , dev@dpdk.org, arybchenko@solarflare.com, stable@dpdk.org Message-ID: <20190403164116.GA1344@bricha3-MOBL.ger.corp.intel.com> References: <20190403160726.1231-1-mohammad.abdul.awal@intel.com> <1807422.QXMQecOh3y@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH 1/3] ethdev: fix null pointer checking X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 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. /Bruce