> -----Original Message----- > From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Friday, April 27, 2018 11:10 PM > To: Shreyansh Jain <shreyansh.j...@nxp.com> > Cc: Jianfeng Tan <jianfeng....@intel.com>; dev@dpdk.org; > tho...@monjalon.net; Olivier Matz <olivier.m...@6wind.com>; Anatoly > Burakov <anatoly.bura...@intel.com> > Subject: Re: [dpdk-dev] [PATCH] eal: fix threads block on barrier > > On Fri, 27 Apr 2018 17:36:56 +0000 > Shreyansh Jain <shreyansh.j...@nxp.com> wrote: > > > > -----Original Message----- > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jianfeng Tan > > > Sent: Friday, April 27, 2018 10:12 PM > > > To: dev@dpdk.org > > > Cc: tho...@monjalon.net; Jianfeng Tan <jianfeng....@intel.com>; > Olivier > > > Matz <olivier.m...@6wind.com>; Anatoly Burakov > > > <anatoly.bura...@intel.com> > > > Subject: [dpdk-dev] [PATCH] eal: fix threads block on barrier > > > > > > 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 <olivier.m...@6wind.com> > > > Cc: Anatoly Burakov <anatoly.bura...@intel.com> > > > > > > Signed-off-by: Jianfeng Tan <jianfeng....@intel.com> > > > > 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 <shreyansh.j...@nxp.com> > > 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.
