From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <thomas@monjalon.net>
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: <xms:PuwcXEoXXeg4kRGT8U6PLMBsvjRlxIUfdseDBWyuzftUJf8gFh3v0Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudejhedgheegucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef
tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufffkjg
hfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcu
oehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkphepjeejrddufeegrddvtd
efrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl
ohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:PuwcXJGDWNTiKliaFlyySUQZOn8Px7oKSjTEO23iqDr36nS3OifylQ>
<xmx:PuwcXL36XyehBOC-dIJguSSCibP_gME9PKt5FmtSw7kyKyITsAksmw>
<xmx:PuwcXHOm1BXDGypgGzt2fCkNBc6sDNbcD-kssAWEt1GHSJeVCmlv_A>
<xmx:P-wcXMmbepDey_jzBPpSw-WIlDGO36uamVWuQl53gm1X-1arZAXHMg>
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 <thomas@monjalon.net>
To: Anatoly Burakov <anatoly.burakov@intel.com>
Cc: dev@dpdk.org, John McNamara <john.mcnamara@intel.com>,
Marko Kovacevic <marko.kovacevic@intel.com>, 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-stable] [dpdk-dev] [PATCH 19.02 v2] 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 <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=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 <anatoly.burakov@intel.com>
> ---
>
> Notes:
> This is the best we can do for 19.02 without breaking ABI.
Applied, thanks