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 5294E1BDE0; Fri, 21 Dec 2018 13:09:29 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3B19C21EAE; Fri, 21 Dec 2018 07:09:28 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 21 Dec 2018 07:09:28 -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=Kzb82icYPchGGxZHtVCAgCcGSNshanH0Pp2fDIEXL6E=; b=kkkBtE2AADr8 2UklnTj1/2sKxFMAqzfMxs0oMcNQDpaiiwKPvg6T1eDWbv4pmgktvaOSi+OIYtCu qhTNJGAZHIYaZARYVo64ctUBlFwC3v3CcUJT4fOVmoB9col/CGfP94sRZYQjmJEC zjd/jg7f7Jo1X8zUeA5p/Q6zkv0RqgU= 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=Kzb82icYPchGGxZHtVCAgCcGSNshanH0Pp2fDIEXL 6E=; b=lznDOqlnk9CYwqACpoLzo9G+EzFnGuU8Zka8hlA2SW2gkZRBJQ77MiZds UbPPC6InOcBKYqHwSuCZqEpgzrfJPO7m5KSA7BvsMTSk3Br1dmt8b7gp+vYIOaAP 6Af9c9QWv1Pn29prvBxJOGRDnydJZSCSgXDfMaw5DhNrx5mYQ6rjrVv8V+pcVR0A bZ3SFsau07TKdTgIcMTTn2sUOrhwpMAMZNozhAL6mKorKjqa7m6fFGGVVB0fqMui GLOfswKrFWkI4p2wgoH/eI1Ko3pSFgsLDbKKRG+8JmprMGCpbg4/T0BJfKwNS3bw QqjamWqSSc4ZoZtlZyuaYzxePCkRg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudejhedgfeejucetufdoteggodetrfdotf 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 52FE9102E8; Fri, 21 Dec 2018 07:09:26 -0500 (EST) From: Thomas Monjalon To: Anatoly Burakov Cc: dev@dpdk.org, stable@dpdk.org, ferruh.yigit@intel.com, bruce.richardson@intel.com, arybchenko@solarflare.com, olivier.matz@6wind.com Date: Fri, 21 Dec 2018 13:09:23 +0100 Message-ID: <8322983.QTS3aZyW4V@xps> In-Reply-To: <884a355bde19652d57c253c6b36036571c4f46ee.1543926108.git.anatoly.burakov@intel.com> References: <884a355bde19652d57c253c6b36036571c4f46ee.1543926108.git.anatoly.burakov@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH 18.11] malloc: fix deadlock when using malloc stats X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2018 12:09:29 -0000 04/12/2018 13:22, 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: > IMO this is the best we can do for 18.11 without breaking ABI. > For 19.02, we can introduce a new global heap lock (something > i should've done in the first place...), so this patch is > not applicable to 19.02. For 19.02, we can fix this properly > by introducing another lock and breaking the EAL ABI. > > Not sure where to put docs update, feedback welcome. This patch is also changing the API, because functions become not thread-safe. I think you should note it in the release notes. About 19.02, do we want to take this patch (with release notes updated)?