From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wiles, Roger Keith" Subject: Re: [PATCH] rte_mempool_dump() crashes with NULL rte_mempool pointer. Date: Sun, 28 Sep 2014 05:38:06 +0000 Message-ID: <831919DA-CEF0-4DA5-AF5D-5B1067F7A602@windriver.com> References: <20140928003719.GA27849@localhost.localdomain> <20140928015504.GA28263@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Cc: "" To: Neil Horman Return-path: In-Reply-To: <20140928015504.GA28263-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> Content-Language: en-US Content-ID: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" On Sep 27, 2014, at 8:55 PM, Neil Horman wrote: > On Sun, Sep 28, 2014 at 01:14:05AM +0000, Wiles, Roger Keith wrote: >>=20 >> On Sep 27, 2014, at 7:37 PM, Neil Horman wrote: >>=20 >>> On Sat, Sep 27, 2014 at 06:35:01PM +0000, Wiles, Roger Keith wrote: >>>>=20 >>>> 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= . >>>>=20 >>>> Signed-off-by: Keith Wiles >>>> --- >>>> lib/librte_mempool/rte_mempool.c | 6 ++++++ >>>> 1 file changed, 6 insertions(+) >>>>=20 >>>> diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte= _mempool.c >>>> index 332f469..efa6a6c 100644 >>>> --- a/lib/librte_mempool/rte_mempool.c >>>> +++ b/lib/librte_mempool/rte_mempool.c >>>> @@ -765,6 +765,12 @@ rte_mempool_dump(FILE *f, const struct rte_mempoo= l *mp) >>>> unsigned common_count; >>>> unsigned cache_count; >>>>=20 >>>> + if ( (f =3D=3D NULL) || (mp =3D=3D NULL) ) { >>>> +#ifdef RTE_LIBRTE_MEMPOOL_DEBUG >>>> + fprintf(stderr, "*** Called rte_mempool_dump(%p, %p) with NULL= argument\n", f, mp); >>>> +#endif /* RTE_LIBRTE_MEMPOOL_DEBUG */ >>>> + return; >>>> + } >>>> fprintf(f, "mempool <%s>@%p\n", mp->name, mp); >>>> fprintf(f, " flags=3D%x\n", mp->flags); >>>> fprintf(f, " ring=3D<%s>@%p\n", mp->ring->name, mp->ring); >>>> --=20 >>>> 2.1.0 >>>>=20 >>>>=20 >>> Maybe use RTE_VERIFY instead? >>> Neil >>>=20 >> I did not think it needs to panic as it is just a debug function and ret= urning would be fine by me, comments? >> Do we have a similar RTE_VERIFY like function that does not panic? >>=20 > If we don't, it would seem useful to make one. It beats having to do spe= cific > condition checking/error reporting. RTE_VERIFY_WARN or some such. > Neil I decided to just use RTE_VERIFY() instead of creating a new macro for now,= it seems this maybe an isolated case. I agree having RTE_VERIFY_WARN() wou= ld be nice, but as I was writing the macro I wanted to return from the func= tion. For this routine =91return=92 would work as it returns (void), but fo= r other routines a value may need to be returned. Need a clean way to exit the routine without causing the macro to understan= d its return values. Just seem to become a bit messy at this point. Multipl= e macros for different return types or make the macros return a boolean val= ue to be tested seemed to more complex then needed. >=20 >> Keith Wiles, Principal Technologist with CTO office, Wind River mobile 9= 72-213-5533 Keith Wiles, Principal Technologist with CTO office, Wind River mobile 972-= 213-5533