Re: [dpdk-dev] [PATCH 1/2] timer: fix null pointer dereference

[Bruce Richardson <bruce.richardson@intel.com>]

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 <stephen@networkplumber.org>
> > 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 <stephen@networkplumber.org>
> > > Sent: Monday, July 15, 2019 10:49 AM
> > > To: Carrillo, Erik G <erik.g.carrillo@intel.com>
> > > 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 <erik.g.carrillo@intel.com> 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 <erik.g.carrillo@intel.com>
> > >
> > > 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?