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 79809A09E4; Sat, 30 Jan 2021 00:37:58 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 03DFF4069B; Sat, 30 Jan 2021 00:37:58 +0100 (CET) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by mails.dpdk.org (Postfix) with ESMTP id CC1D240699 for ; Sat, 30 Jan 2021 00:37:56 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 40473EA1; Fri, 29 Jan 2021 18:37:55 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 29 Jan 2021 18:37:55 -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= KF1uZhmLYdjjaKl/6VO2ZQh8r6YU6RmS7HHk8Z7Q2J8=; b=ZNeFqO5VhgWPRXYV Ue/Jm5v/sOkQ8d1MjNiM4Ig5ACxV4yYO10MQpQtRR+exVL9Ny/iXaH+jFsEIsIcb H1idvZgiNGdSm7G2+nJ+P0GNmxNAftTmoxMHTnN1Hr2PiqNFuQDVaZgt+z+QYx3D 03eLv89bV8lkTJopz2pqp2NHrDAhErqli+rjf9ovZ3UEEb1FmuJDGyppcQsLofbc N6EpVhbFzLIYnsb0UZmb/99wJnhRjIg3lX9UPISdU5VL004YtL76HGZbvcFLtpm6 gITVFfYHcIBKkK0gI9fg3rx4hoEoKbsLwrtePmZL20gSDzPTK+kSRPtNoCy0BhKn WgqMtQ== 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=KF1uZhmLYdjjaKl/6VO2ZQh8r6YU6RmS7HHk8Z7Q2 J8=; b=ekZTZZShPIdpIm9WETtbOkLmPtwcAfPR34m0ph6Cay5TlOeLaZiQX3Uy2 R9ULwDd7qNz+6KuPTR31g3hE1lq0+7tjUEoojFSSIj0cLV64ye48M3VgW8ZMdE/x gMCcuquxixsiZRwNc+shY0vGRVEouPtE8M80WEamXDPLUXoKkRLP2siMWAK3OUht 0UxXvRqNqeWIMr7nQ8qjZMUOOlTKTunWbJ14L7fUthz1mCdDZYModM7uL7pqxeCq 3K53D2hMYOlrWs3IQBZ78X7v+Ztmpn2eZaEBW4Kq1mCY4xk6BBmQA5/SRHOQdaYf X1HbN53HgQ7Tm5ng13Cixg59WhkEg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeefgddutdcutefuodetggdotefrodftvf 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 AB02F24005C; Fri, 29 Jan 2021 18:37:53 -0500 (EST) From: Thomas Monjalon To: "Burakov, Anatoly" Cc: dev@dpdk.org, james.r.harris@intel.com Date: Sat, 30 Jan 2021 00:37:51 +0100 Message-ID: <3438169.Cr2niX57Iq@thomas> In-Reply-To: References: <4e0688f841f6ba2408fde949aabce8e36c0d46f0.1611934186.git.anatoly.burakov@intel.com> <16449461.VCXEoCD3cp@thomas> 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 17:07, Burakov, Anatoly: > On 29-Jan-21 3:40 PM, Thomas Monjalon wrote: > > 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? > > I couldn't reproduce this using autotests, but Jim has SPDK tests which > triggered this error. > > Since this is dependent upon secondary process, any test would > necessarily have to be manual here, i think. > > >> Fixes: 7ac31e82bc8f ("mem: improve parameter checking on memory hotplug") > >> > >> Reported-by: Jim Harris > >> > > > > No need of blank line here. > > Need to update my scripts :P > > >> Signed-off-by: Anatoly Burakov > >> --- [...] > >> + /* > >> + * 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? > > Yes. > > >> + * socket ID's are always lower than RTE_MAX_NUMA_NODES. > >> + */ Applied with minor changes, thanks.