From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id DBC281B1EC; Thu, 4 Oct 2018 00:36:51 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6CB0021949; Wed, 3 Oct 2018 18:36:50 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 03 Oct 2018 18:36:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=Bj/PzNkl0Ag5DbpXXSNqaxOj5AMueN/rntd1SjV1Amw=; b=hiTEFjpWvi2Y ZBxmiy7EIX3bkpGl6otvk7Zt0ZfnEhDolAyN9RtdqT6k5+Zams5AGZ2LxAT8eRz8 HzTn5GkK4nSWU8RYz86THe3GgPioiww9eA+Vp1sqSG8fLxMhsO6+czmyhvNZmztQ dJ5hVeydFntLLkyWGrecdrVCz/QvmZY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Bj/PzNkl0Ag5DbpXXSNqaxOj5AMueN/rntd1SjV1A mw=; b=TQuKaHU+2BmvIhTwZaTYdtjnrCF5b2RPu+ubjWdkyAgCE6ZKM70fRsp/N 7bINxqRpAmD3LY9tZXHFuWurQSpuJPhhGPzH7DZLa+Xb8VOfDhAEhMLqomxSePyn 3DunzLAuLRe0V/HZwljjk0mLYOGpAl44uN/rjYS01loEJmcQh1+FDHPp5PeNxm4Y r0WwPjqebzTs7PkJnm68oiCDQuiwcgfEluu916ybSIpjXIf8Rf4KVmXsmW8YOnj4 CHMIiXoGQHFz8ijKhth/n4GekhxiY/eex9ierX9m6aRa7wEA95XCD1TegocN78zr jl6hGFMf6ZFlFxYaV5sCmY6fA0abA== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id C6CB3102DD; Wed, 3 Oct 2018 18:36:48 -0400 (EDT) From: Thomas Monjalon To: Anatoly Burakov Cc: stable@dpdk.org, Ilya Maximets , dev@dpdk.org, solal.pirelli@gmail.com Date: Thu, 04 Oct 2018 00:36:47 +0200 Message-ID: <1780284.rQHulcP352@xps> In-Reply-To: <20180921110038eucas1p1185f3275e6d99f285f44a299dd3b210d~WZT3JUk-I2589925899eucas1p12@eucas1p1.samsung.com> References: <7e4178219213303b982e505ae4cb4387d9d3814a.1537447684.git.anatoly.burakov@intel.com> <2f0bea6a3860143bfbcf31142440a0e4db7c7933.1537521888.git.anatoly.burakov@intel.com> <20180921110038eucas1p1185f3275e6d99f285f44a299dd3b210d~WZT3JUk-I2589925899eucas1p12@eucas1p1.samsung.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v3] mem: fix undefined behavior in NUMA code X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 22:36:52 -0000 21/09/2018 13:02, Ilya Maximets: > On 21.09.2018 12:27, Anatoly Burakov wrote: > > When NUMA-aware hugepages config option is set, we rely on > > libnuma to tell the kernel to allocate hugepages on a specific > > NUMA node. However, we allocate node mask before we check if > > NUMA is available in the first place, which, according to > > the manpage [1], causes undefined behaviour. > > > > Fix by only using nodemask when we have NUMA available. > > > > [1] https://linux.die.net/man/3/numa_alloc_onnode > > > > Bugzilla ID: 20 > > > > Fixes: 1b72605d2416 ("mem: balanced allocation of hugepages") > > Cc: i.maximets@samsung.com > > Cc: stable@dpdk.org > > > > Signed-off-by: Anatoly Burakov > > --- > > > > Notes: > > v3: > > - Fix potential memory leak if socket-mem was not specified > > > > v2: > > - Improve readability as per Ilya's comment > > > > lib/librte_eal/linuxapp/eal/eal_memory.c | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > LGTM, > Acked-by: Ilya Maximets Applied, thanks