DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Bruce Richardson <bruce.richardson@intel.com>,
	Neil Horman <nhorman@tuxdriver.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] rte_mempool_dump() crashes with NULL rte_mempool	pointer.
Date: Thu, 02 Oct 2014 09:47:19 +0200	[thread overview]
Message-ID: <2861812.mN4X60CA8c@xps13> (raw)
In-Reply-To: <20141001160548.GA6676@BRICHA3-MOBL>

2014-10-01 17:05, Bruce Richardson:
> On Wed, Oct 01, 2014 at 12:01:10PM -0400, Neil Horman wrote:
> > On Wed, Oct 01, 2014 at 04:43:10PM +0100, Bruce Richardson wrote:
> > > On Wed, Oct 01, 2014 at 11:02:27AM -0400, Neil Horman wrote:
> > > > On Wed, Oct 01, 2014 at 03:36:45PM +0200, Thomas Monjalon wrote:
> > > > > 2014-09-28 08:27, Neil Horman:
> > > > > > On Sun, Sep 28, 2014 at 05:28:44AM +0000, Wiles, Roger Keith wrote:
> > > > > > > Check the FILE *f and rte_mempool *mp pointers for NULL and
> > > > > > > return plus print out a message if RTE_LIBRTE_MEMPOOL_DEBUG is enabled.
> > > > > > > 
> > > > > > > Signed-off-by: Keith Wiles <keith.wiles@windriver.com>
> > > > > > 
> > > > > > I'm fine with this, as I think passing in a NULL mempool is clearly a bug here,
> > > > > > thats worth panicing over, though I wouldnt mind if we did a RTE_VERIFY_WARN
> > > > > > macro here instead using what I suggested in my other note
> > > > > 
> > > > > Passing a NULL mempool to rte_mempool_dump() is a bug in the application.
> > > > > If you look elsewhere in the DPDK code, you'll see that it's not common to do
> > > > > such check on input parameters.
> > > > > A similar discussion already happened few months ago:
> > > > > 	http://dpdk.org/ml/archives/dev/2014-June/003900.html
> > > > > 
> > > > Not sure what your point is here Thomas.  I think we're all in agreement that
> > > > NULL is a bad value to pass in here.  Are you asserting that we shouldn't bother
> > > > with a NULL check at all and just accept the crash as it is?
> > > >
> > > 
> > > In the general case:
> > > * Code in the datapath should not have things like NULL checks
> > > * However, datapath code should generally have a debug option which turns 
> > >   these checks on to help debugging if needed. 
> > > * Code not in the datapath probably should have these checks.
> > > 
> > Ok, I can understand that, but I would hope that rte_mempool_dump isn't in the
> > datapath, its rather by definition a debug function, isn't it?
> > Neil
> 
> Yes, agreed.  [So it probably should have the NULL check].

I have many arguments to not do this check:
1) If it was a coding rule to do this kind of check, it should be done in
almost every functions.
2) It's quite common to not do this check, e.g. what happen with memcpy(NULL,NULL)?
3) Why check only NULL value? 1 and 2 are also some invalid values...

-- 
Thomas

  reply	other threads:[~2014-10-02  7:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-27 18:35 [dpdk-dev] [PATCH] " Wiles, Roger Keith
2014-09-28  0:37 ` Neil Horman
2014-09-28  1:10   ` Wiles, Roger Keith
2014-09-28  1:14   ` Wiles, Roger Keith
2014-09-28  1:55     ` Neil Horman
2014-09-28  5:38       ` Wiles, Roger Keith
2014-09-28 12:25         ` Neil Horman
2014-09-28  5:28 ` [dpdk-dev] [PATCH v2] " Wiles, Roger Keith
2014-09-28 12:27   ` Neil Horman
2014-09-28 14:37     ` Wiles, Roger Keith
2014-10-01 13:36     ` Thomas Monjalon
2014-10-01 15:02       ` Neil Horman
2014-10-01 15:43         ` Bruce Richardson
2014-10-01 15:57           ` Wiles, Roger Keith
2014-10-01 16:01           ` Neil Horman
2014-10-01 16:05             ` Bruce Richardson
2014-10-02  7:47               ` Thomas Monjalon [this message]
2014-10-02 11:37                 ` Neil Horman
2014-11-27 16:32                   ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2861812.mN4X60CA8c@xps13 \
    --to=thomas.monjalon@6wind.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=nhorman@tuxdriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).