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

["Wiles, Roger Keith" <keith.wiles@windriver.com>]

On Sep 28, 2014, at 7:27 AM, Neil Horman <nhorman@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@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