From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C1A60A09E4; Fri, 29 Jan 2021 16:40:38 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A611F4067B; Fri, 29 Jan 2021 16:40:38 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id CD37540395 for ; Fri, 29 Jan 2021 16:40:37 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 183525C0255; Fri, 29 Jan 2021 10:40:37 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 29 Jan 2021 10:40:37 -0500 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=fm3; bh= hNkUqZ118Nd7LtzT8ALQT28AN4l3nOU1h9jKwSDcjiU=; b=qWvA72ozy5doSwmW ICuxUmJTI1KGkGN+x8BHyrQXvtfw0HuUqToto6kUd8+s0glGWOLqfDpz5bdAD94O yChcFGDLJjoAy24I0TitkkzzVsSEP0Jl1Q4LV/Ton/a7/nisfoKP9KPggKaN9ZNW kwXkn1O7lQ5rXEj0or/2Ep082lrvgC4JsFcWHbIP9AFEee8LdRpwBkA03QJpLSDF Tf3BRNvdEK0JPHtfkivkhb3NWxccDu2xwJE9gLSe6O64v6e0zDnEHVG96zohD3Lk MHq05qMrjtw11g+x5U4TQg7yLABEcpsVz9YyqYqWop3bZLvKITJRI6FEFqDPOyA5 032Iug== 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=fm1; bh=hNkUqZ118Nd7LtzT8ALQT28AN4l3nOU1h9jKwSDcj iU=; b=pwKLNBxw98sE7Ik3KSraAX+cuatnPxZqcBKXjmbSjzvC7rQFHB1mNMzAk xw4Lj3/y4LE4R6aBGwAxdhMEuI3pjBcDnXHWnv6uz08worR7kygnCnIldi9LOLRp zpcWj/AfPIiPat2f6F0qKQPh85vf8rOV9dMgDsEeCP/g2xCmtMkR31Gy5SrGPUd2 B8VgX8SWX0Wfhu/XaqGn0Mfam/zXOVLMpMTClV99GRqIcC4mvc6NwUfRmdxE7ypb 6WY+j6hIFCXG0wAV43cWFJzLRhYpX0DWpNVbScoQWeOudqI006Q6tt9AKhFgT73r 3NJE+4jJnEgiw+pUqSmJaWJFUBoYA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedvgdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth 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 5370D1080064; Fri, 29 Jan 2021 10:40:36 -0500 (EST) From: Thomas Monjalon To: Anatoly Burakov Cc: dev@dpdk.org, james.r.harris@intel.com Date: Fri, 29 Jan 2021 16:40:35 +0100 Message-ID: <16449461.VCXEoCD3cp@thomas> In-Reply-To: <4e0688f841f6ba2408fde949aabce8e36c0d46f0.1611934186.git.anatoly.burakov@intel.com> References: <4e0688f841f6ba2408fde949aabce8e36c0d46f0.1611934186.git.anatoly.burakov@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] mem: fix deadlock on secondary allocation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 29/01/2021 16:29, Anatoly Burakov: > Previous fix used `rte_malloc_heap_socket_is_external()` to check if the > heap was an external heap. However, that API is thread-safe, and when > we're inside the allocation process, we're already write-locked, so > calling `rte_malloc_heap_socket_is_external()` will result in a > deadlock followed by a timeout. > > Fix it by replacing the API call with a check against maximum number of > NUMA nodes, because external heaps always have higher socket ID's. Is there some unit tests for such thing? > > Fixes: 7ac31e82bc8f ("mem: improve parameter checking on memory hotplug") > > Reported-by: Jim Harris > No need of blank line here. > Signed-off-by: Anatoly Burakov > --- > lib/librte_eal/common/malloc_mp.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/lib/librte_eal/common/malloc_mp.c b/lib/librte_eal/common/malloc_mp.c > index 0b19d4d5fb..b1f7f7824b 100644 > --- a/lib/librte_eal/common/malloc_mp.c > +++ b/lib/librte_eal/common/malloc_mp.c > - /* for allocations, we must only use internal heaps */ > - if (rte_malloc_heap_socket_is_external(heap->socket_id)) { > + /* > + * for allocations, we must only use internal heaps, but since the > + * rte_malloc_heap_socket_is_external() is thread-safe and we're already > + * read-locked, we'll have to take advantage of the fac that internal fac -> fact? > + * socket ID's are always lower than RTE_MAX_NUMA_NODES. > + */ > + if (heap->socket_id >= RTE_MAX_NUMA_NODES) {