From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Conole Subject: Re: [PATCH v5 08/26] eal: do not panic on memzone initialization fails Date: Tue, 28 Feb 2017 09:46:58 -0500 Message-ID: References: <20170225160309.31270-1-aconole@redhat.com> <20170227161811.12309-1-aconole@redhat.com> <20170227161811.12309-9-aconole@redhat.com> <20170228142739.GB15368@bricha3-MOBL3.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain Cc: dev@dpdk.org, Stephen Hemminger To: Bruce Richardson Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id BE9B22BB1 for ; Tue, 28 Feb 2017 15:46:59 +0100 (CET) In-Reply-To: <20170228142739.GB15368@bricha3-MOBL3.ger.corp.intel.com> (Bruce Richardson's message of "Tue, 28 Feb 2017 14:27:39 +0000") List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Bruce Richardson writes: > On Mon, Feb 27, 2017 at 11:17:53AM -0500, Aaron Conole wrote: >> When memzone initialization fails, report the error to the calling >> application rather than panic(). Without a good way of detaching / >> releasing hugepages, at this point the application will have to restart. >> >> Signed-off-by: Aaron Conole >> --- >> lib/librte_eal/linuxapp/eal/eal.c | 7 +++++-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c >> index a671ed4..1e54ca1 100644 >> --- a/lib/librte_eal/linuxapp/eal/eal.c >> +++ b/lib/librte_eal/linuxapp/eal/eal.c >> @@ -839,8 +839,11 @@ rte_eal_init(int argc, char **argv) >> /* the directories are locked during eal_hugepage_info_init */ >> eal_hugedirs_unlock(); >> >> - if (rte_eal_memzone_init() < 0) >> - rte_panic("Cannot init memzone\n"); >> + if (rte_eal_memzone_init() < 0) { >> + RTE_LOG(ERR, EAL, "Cannot init memzone\n"); > > Any particular reason why not "rte_eal_init_alert" as with the other > cases? I only used rte_eal_init_alert() for cases which occur before logging happens, but I am not opposed to switching it for all the cases. I'll swap them all for v6. Thanks again for the review, Bruce! -Aaron