From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id CEFD31BD66; Fri, 21 Dec 2018 14:35:59 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5C26B2297C; Fri, 21 Dec 2018 08:35:59 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 21 Dec 2018 08:35:59 -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=mesmtp; bh=obPLOxho81Zt1KAXy9wqIQPb2gD0HZ/phYNKUPWTUsE=; b=LceS3Ilc2/aq +qShmL/0nlS2f0sAxXol7fBQKOITTXo7pKHzT4jFuila1/nkrK8+quJ5U4JO8Vyk 93hbtCJCH6KGzrXAdKy6k6+TjTwP8TuZRfw6KLawsewDlqRLirYsRqOOKN8/9UGZ bvRM9/AbCg9EZFp/ZD7ZLpQUB5Urxx0= 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=obPLOxho81Zt1KAXy9wqIQPb2gD0HZ/phYNKUPWTU sE=; b=IoGEXHsRxfoIEu4pHnfo76ioAxJYimHV0KKWGcxpp7CUORNjZklU26RDz PaoTqsXEh6P/W0uOtGNFPcDxdqQVQepx+nU8X85U0NYRou71Z3JOhm9PaD2fJWxj 28iwnOvtm6o6p0iUmuwFXBTAi14eqzZXR3lDVE/+1sxcCMUJKpvQ6lEVdyf9MKeq aIT0HuDHKDZfL666JuQvzlz5MVk57E65N2vp5LXSOXxPfX7ZGLpS8ARqqwuQoAqz M/vWjWhEx/yOdIom6HDwqFJBO2hk2H7VvigMHAZyPzloezDP9VphTl28ecZljPU0 GKLjf51IWLCeIsip2piQDztyPRwaA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudejhedgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufffkjg hfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcu oehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkphepjeejrddufeegrddvtd efrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd 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 038E7E4445; Fri, 21 Dec 2018 08:35:57 -0500 (EST) From: Thomas Monjalon To: Anatoly Burakov Cc: dev@dpdk.org, John McNamara , Marko Kovacevic , stable@dpdk.org Date: Fri, 21 Dec 2018 14:35:57 +0100 Message-ID: <7780238.sPL5XOYxUe@xps> In-Reply-To: <517a31eda38a8334a9a9dbc941f0e2bcc067073c.1545395127.git.anatoly.burakov@intel.com> References: <884a355bde19652d57c253c6b36036571c4f46ee.1543926108.git.anatoly.burakov@intel.com> <517a31eda38a8334a9a9dbc941f0e2bcc067073c.1545395127.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 19.02 v2] malloc: fix deadlock when using malloc stats 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: Fri, 21 Dec 2018 13:36:00 -0000 21/12/2018 13:26, Anatoly Burakov: > Currently, malloc statistics and external heap creation code > use memory hotplug lock as a way to synchronize accesses to > heaps (as in, locking the hotplug lock to prevent list of heaps > from changing under our feet). At the same time, malloc > statistics code will also lock the heap because it needs to > access heap data and does not want any other thread to allocate > anything from that heap. > > In such scheme, it is possible to enter a deadlock with the > following sequence of events: > > thread 1 thread 2 > rte_malloc() > rte_malloc_dump_stats() > take heap lock > take hotplug lock > failed to allocate, > attempt to take > hotplug lock > attempt to take heap lock > > Neither thread will be able to continue, as both of them are > waiting for the other one to drop the lock. Adding an > additional lock will require an ABI change, so instead of > that, make malloc statistics calls thread-unsafe with > respect to creating/destroying heaps. > > Fixes: 72cf92b31855 ("malloc: index heaps using heap ID rather than NUMA node") > Cc: stable@dpdk.org > > Signed-off-by: Anatoly Burakov > --- > > Notes: > This is the best we can do for 19.02 without breaking ABI. Applied, thanks