Re: [PATCH v2] rte_mempool_dump() crashes with NULL rte_mempool pointer.

[Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>]

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-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
> ---
>  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