From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wiles, Roger Keith" Subject: Re: [PATCH v2] rte_mempool_dump() crashes with NULL rte_mempool pointer. Date: Sun, 28 Sep 2014 14:37:30 +0000 Message-ID: <00F93A0F-9269-4A12-907A-8AFA2E3BB502@windriver.com> References: <05E7C1C5-2730-4BE3-B808-6F69821F7898@windriver.com> <20140928122706.GB30445@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "" To: Neil Horman Return-path: In-Reply-To: <20140928122706.GB30445-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> Content-Language: en-US Content-ID: <14EC9D4BF311BB4D97D7C038E0610EE5@local> 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 28, 2014, at 7:27 AM, Neil Horman wrote: > On Sun, Sep 28, 2014 at 05:28:44AM +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 | 3 +++ >> 1 file changed, 3 insertions(+) >>=20 >> diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_m= empool.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; >>=20 >> + RTE_VERIFY(f !=3D NULL); >> + RTE_VERIFY(mp !=3D NULL); >> + >> 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 >> Keith Wiles, Principal Technologist with CTO office, Wind River mobile 9= 72-213-5533 >>=20 >>=20 >=20 > 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_W= ARN > macro here instead using what I suggested in my other note > Neil Maybe I can add RTE_VERIFY_WARN() later or someone else can. >=20 Keith Wiles, Principal Technologist with CTO office, Wind River mobile 972-= 213-5533