From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.windriver.com (mail1.windriver.com [147.11.146.13]) by dpdk.org (Postfix) with ESMTP id 0F07D68A2 for ; Sun, 28 Sep 2014 07:31:39 +0200 (CEST) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail1.windriver.com (8.14.9/8.14.5) with ESMTP id s8S5c72W021177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Sep 2014 22:38:08 -0700 (PDT) Received: from ALA-MBB.corp.ad.wrs.com ([169.254.1.18]) by ALA-HCA.corp.ad.wrs.com ([147.11.189.40]) with mapi id 14.03.0174.001; Sat, 27 Sep 2014 22:38:07 -0700 From: "Wiles, Roger Keith" To: Neil Horman Thread-Topic: [dpdk-dev] [PATCH] rte_mempool_dump() crashes with NULL rte_mempool pointer. Thread-Index: AQHP2oG/7+zUgDJSJ0eBA/ewM6tenJwWKQ2AgAAKRoCAAAtzAIAAPlEA 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> In-Reply-To: <20140928015504.GA28263@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.25.40.166] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dpdk-dev] [PATCH] rte_mempool_dump() crashes with NULL rte_mempool pointer. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 05:31:40 -0000 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