From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 29C6DAAC5 for ; Fri, 27 Apr 2018 21:52:28 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9C26921BD0; Fri, 27 Apr 2018 15:52:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 27 Apr 2018 15:52:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=I0bLeUipK39vr2UNozygzapnNN 01wSnSjxIbOdmL1lQ=; b=LVZDizGlhH5dVVMMn5tIfJJtas2XYPITv+6cfQnDpe uUTTDc3uBO/9RG6A4q+8sxqEP2f5krLhUnfBwpzLDXtDxZFngs2xfF7cJ/Ksdll4 HJ/RihifHXu+6krFN30cqyO9+rJlGV5l2+UL1MYnhivucO3MVv4RGEnzIBr53tDo 0= 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-sender:x-me-sender:x-sasl-enc; s=fm2; bh=I0bLeU ipK39vr2UNozygzapnNN01wSnSjxIbOdmL1lQ=; b=Vdw/Qu7e7C0rjdOshvZVJM J694Q+5Q70coa11l3ODIBbJp7UnMAxX+rFRIONMT8xyJqGNrr2PJJoF1eUraXyuk zXKbzOGlxotzej6iFtJIFa6vcLmPgEN8w9wcyyIVhTbEOw4NMBIw04Zrd3eGzQ/x XyDMfVc0ntICQlHKpbsnIrK2wM0oOHNv58jv7y3XnoFoG8rjCHrjbO1XfI9GFOcm FUN3jaNPpKBJkBKnsU4KaSBf8zqnBnX6V+qW9Cjg/JbRmy1kvbM8hQkvyCBJ9zl4 DnFm9uNCca9QljX50sKg0SlB5xldyupW++/eHQ1YA8ta/nCxiY/S49L5AP1BjEXg == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id AA05FE5098; Fri, 27 Apr 2018 15:52:27 -0400 (EDT) From: Thomas Monjalon To: Shreyansh Jain , Jianfeng Tan Cc: dev@dpdk.org, Stephen Hemminger , Olivier Matz , Anatoly Burakov Date: Fri, 27 Apr 2018 21:52:26 +0200 Message-ID: <13763738.ezdo4hZiut@xps> In-Reply-To: References: <1524847302-88110-1-git-send-email-jianfeng.tan@intel.com> <20180427103945.511a118e@xeon-e3> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] eal: fix threads block on barrier 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, 27 Apr 2018 19:52:29 -0000 27/04/2018 19:45, Shreyansh Jain: > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > Shreyansh Jain wrote: > > > From: Jianfeng Tan > > > > Below commit introduced pthread barrier for synchronization. > > > > But two IPC threads block on the barrier, and never wake up. > > > > > > > > (gdb) bt > > > > #0 futex_wait (private=0, expected=0, futex_word=0x7fffffffcff4) > > > > at ../sysdeps/unix/sysv/linux/futex-internal.h:61 > > > > #1 futex_wait_simple (private=0, expected=0, > > > > futex_word=0x7fffffffcff4) > > > > at ../sysdeps/nptl/futex-internal.h:135 > > > > #2 __pthread_barrier_wait (barrier=0x7fffffffcff0) at > > > > pthread_barrier_wait.c:184 > > > > #3 rte_thread_init (arg=0x7fffffffcfe0) > > > > at ../dpdk/lib/librte_eal/common/eal_common_thread.c:160 > > > > #4 start_thread (arg=0x7ffff6ecf700) at pthread_create.c:333 > > > > #5 clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 > > > > > > > > Through analysis, we find the barrier defined on the stack > > > > could be the root cause. This patch will change to use heap > > > > memory as the barrier. > > > > > > > > Fixes: d651ee4919cd ("eal: set affinity for control threads") > > > > > > > > Cc: Olivier Matz > > > > Cc: Anatoly Burakov > > > > > > > > Signed-off-by: Jianfeng Tan > > > > > > Though I have seen Stephen's comment on this (possibly a library > > bug), this at least fixes an issue which was dogging dpaa and dpaa2 - > > generating bus errors and futex errors with variation in core masks > > provided to applications. > > > > > > Thanks a lot for this. > > > > > > Acked-by: Shreyansh Jain Applied, thanks Jianfeng. > > Could you verify there is not a use after free by using valgrind or > > some library that poisons memory on free. > > I will probably do that soon - but for the time being I don't want > this issue to block the dpaa/dpaa2 for RC1 - these drivers were > completely unusable without this patch. Please Shreyansh, continue the analysis of this bug. Thanks