From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 92F97A0471 for ; Tue, 16 Jul 2019 10:31:12 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 62E542BE1; Tue, 16 Jul 2019 10:31:12 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id CB6DFDE3 for ; Tue, 16 Jul 2019 10:31:09 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2019 01:31:08 -0700 X-IronPort-AV: E=Sophos;i="5.63,497,1557212400"; d="scan'208";a="342642483" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.1.207]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2019 01:31:05 -0700 Date: Tue, 16 Jul 2019 09:31:02 +0100 From: Bruce Richardson To: "Carrillo, Erik G" Cc: 'Stephen Hemminger' , "'thomas@monjalon.net'" , "'dev@dpdk.org'" Message-ID: <20190716083102.GA561@bricha3-MOBL.ger.corp.intel.com> References: <1563205172-352-1-git-send-email-erik.g.carrillo@intel.com> <1563205172-352-2-git-send-email-erik.g.carrillo@intel.com> <20190715084841.4f6baebf@hermes.lan> 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-dev] [PATCH 1/2] timer: fix null pointer dereference 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" On Mon, Jul 15, 2019 at 07:48:09PM +0000, Carrillo, Erik G wrote: > > -----Original Message----- > > From: Carrillo, Erik G > > Sent: Monday, July 15, 2019 11:04 AM > > To: Stephen Hemminger > > Cc: thomas@monjalon.net; dev@dpdk.org; stable@dpdk.org > > Subject: RE: [dpdk-dev] [PATCH 1/2] timer: fix null pointer dereference > > > > Hi Stephen, > > > > > -----Original Message----- > > > From: Stephen Hemminger > > > Sent: Monday, July 15, 2019 10:49 AM > > > To: Carrillo, Erik G > > > Cc: thomas@monjalon.net; dev@dpdk.org; stable@dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH 1/2] timer: fix null pointer > > > dereference > > > > > > On Mon, 15 Jul 2019 10:39:31 -0500 > > > Erik Gabriel Carrillo wrote: > > > > > > > If the timer subsystem is not initialized before rte_timer_manage > > > > (for > > > > example) is invoked, a pointer to a shared hugepage memory region > > > > will still be null and dereferenced when it is checked for validity; > > > > handle this case. > > > > > > > > Fixes: c0749f7096c7 ("timer: allow management in shared memory") > > > > Cc: stable@dpdk.org > > > > > > > > Signed-off-by: Erik Gabriel Carrillo > > > > > > I have mixed feelings about this patch. > > > Any calls to rte_timer before rte_timer_subsystem_init is not a valid usage. > > > Better to kill the application. > > > > Ok, that sounds like a better approach. I'll update the patch and resubmit. > > > > I added a call to rte_exit() in the timer_data_valid() function for the case where the library is uninitialized, but checkpatches.sh issues the following warning: > > "Warning in /lib/librte_timer/rte_timer.c: > Using rte_panic/rte_exit" > > According to the comments in the script, we should refrain from new additions of rte_panic() and rte_exit() in the lib subtree. In light of this, should we still proceed with this approach? It does seem like it would be useful. > I don't think we should ever put panics or exits in our library code, so I think the immediate choices are to either leave things as-is and allow app to crash for invalid use, or else catch the error and return a suitable error code to the user. I think I'd prefer the latter. However, given that the error condition is not having the timer subsystem initialized, is there the possibility of a third option to just go and initialize before continuing in the timer_manage() function?