From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 3A638ADCE for ; Wed, 8 Jun 2016 14:42:42 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 08 Jun 2016 05:42:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,439,1459839600"; d="scan'208";a="824103410" Received: from smonroyx-mobl.ger.corp.intel.com (HELO [10.237.220.56]) ([10.237.220.56]) by orsmga003.jf.intel.com with ESMTP; 08 Jun 2016 05:42:32 -0700 To: Daniel Mrzyglod , david.marchand@6wind.com References: <1461776764-108197-1-git-send-email-danielx.t.mrzyglod@intel.com> Cc: dev@dpdk.org From: Sergio Gonzalez Monroy Message-ID: Date: Wed, 8 Jun 2016 13:42:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1461776764-108197-1-git-send-email-danielx.t.mrzyglod@intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] eal/linux: fix undefined allocation of 0 bytes (CERT MEM04-C; CWE-131) 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: Wed, 08 Jun 2016 12:42:42 -0000 On 27/04/2016 18:06, Daniel Mrzyglod wrote: > Fix issue reported by clang scan-build > > there is a chance that nr_hugepages will be 0 if conditions for loop > for (i = 0; i < (int) internal_config.num_hugepage_sizes; i++) > will be unmeet. > > Fixes: b6a468ad41d5 ("memory: add --socket-mem option") > > Signed-off-by: Daniel Mrzyglod > --- > lib/librte_eal/linuxapp/eal/eal_memory.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c > index 5b9132c..e94538e 100644 > --- a/lib/librte_eal/linuxapp/eal/eal_memory.c > +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c > @@ -1114,6 +1114,8 @@ rte_eal_hugepage_init(void) > * processing done on these pages, shared memory will be created > * at a later stage. > */ > + if (nr_hugepages == 0) > + goto fail; > tmp_hp = malloc(nr_hugepages * sizeof(struct hugepage_file)); > if (tmp_hp == NULL) > goto fail; The behavior of malloc(0) is implementation-defined, but on Linux man page it says that returns NULL. So strictly speaking, without the patch the outcome is the same cause malloc(0) will return NULL. Now, I'd consider the patch not needed but it doesn't really harm either. Anyone else has comments/thoughts about it? Regarding the patch itself, I think the title and commit message need to be modify to reflect that the patch goal is to handle nr_hugepages = 0 case without relying in malloc to return NULL. Sergio