On Sep 28, 2014, at 7:27 AM, Neil Horman <nhorman at tuxdriver.com> wrote:
> 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 at windriver.com> >> --- >> lib/librte_mempool/rte_mempool.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/lib/librte_mempool/rte_mempool.c >> b/lib/librte_mempool/rte_mempool.c >> index 332f469..0f71f10 100644 >> --- a/lib/librte_mempool/rte_mempool.c >> +++ b/lib/librte_mempool/rte_mempool.c >> @@ -765,6 +765,9 @@ rte_mempool_dump(FILE *f, const struct rte_mempool *mp) >> unsigned common_count; >> unsigned cache_count; >> >> + RTE_VERIFY(f != NULL); >> + RTE_VERIFY(mp != NULL); >> + >> fprintf(f, "mempool <%s>@%p\n", mp->name, mp); >> fprintf(f, " flags=%x\n", mp->flags); >> fprintf(f, " ring=<%s>@%p\n", mp->ring->name, mp->ring); >> -- >> 2.1.0 >> >> Keith Wiles, Principal Technologist with CTO office, Wind River mobile >> 972-213-5533 >> >> > > 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 > Neil Maybe I can add RTE_VERIFY_WARN() later or someone else can. > Keith Wiles, Principal Technologist with CTO office, Wind River mobile 972-213-5533
