Re: [dpdk-dev] [PATCH] eal: fix threads block on barrier

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri, 27 Apr 2018 21:52:26 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:

> 27/04/2018 19:45, Shreyansh Jain:
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]  
> > > Shreyansh Jain <shreyansh.jain@nxp.com> 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 <olivier.matz@6wind.com>
> > > > > Cc: Anatoly Burakov <anatoly.burakov@intel.com>
> > > > >
> > > > > Signed-off-by: Jianfeng Tan <jianfeng.tan@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.jain@nxp.com>  
> 
> 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
> 
> 

The pthread_barrier should also be destroyed when it is no longer needed.