[dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory

The initialization me->locked=1 in lock() must happen before next->locked=0 in unlock(), otherwise a thread may hang forever, waiting me->locked become 0. On weak memory systems (such as ARMv8), the current implementation allows me->locked=1 to be reordered with announcing the n

Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory

Diogo Behrens writes: > Subject: [PATCH] librte_eal: fix mcslock hang on weak memory > > The initialization me->locked=1 in lock() must happen before > next->locked=0 in unlock(), otherwise a thread may hang forever, > waiting me->locked become 0. On weak memory systems (such as ARMv

Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory

Hi Phil, thanks for taking a look at this. Indeed, the cmpxchg will have release semantics, but implicit barriers do not provide the same ordering guarantees as DMB ISH, ie, atomic_thread_fence(__ATOMIC_ACQ_REL). Let me try to explain the scenario. Here is a pseudo-ARM assembly with the instru

Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory

Hi Diogo, Thanks for your explanation. As documented in Arm ARM B2.9.5 Load-Exclusive and Store-Exclusive instruction usage restrictions: " Between the Load-Exclusive and the Store-Exclusive, there are no explicit memory accesses, preloa

Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory

Hi Diogo, Thanks for your explanation. As documented in https://developer.arm.com/documentation/ddi0487/fc  B2.9.5 Load-Exclusive and Store-Exclusive instruction usage restrictions: " Between the Load-Exclusive and the Store-Exclusive, there are no explicit memory accesses, preloads, direct

Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory

s Monjalon [mailto:tho...@monjalon.net] > Sent: Tuesday, October 6, 2020 11:50 PM > To: Phil Yang ; Diogo Behrens ; > Honnappa Nagarahalli > Cc: dev@dpdk.org; nd > Subject: Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory > > 31/08/2020 20:45, Honnappa Nag

Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory

ng to happen, one should make the last store of P1 to > have a "release" barrier, ie, STLR. > > > > This is equivalent to the reordering occurring in the mcslock of librte_eal. > > > > Best regards, > > -Diogo > > > > -Original Message--

Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory

ld make the last store of P1 > > > to > > have a "release" barrier, ie, STLR. > > > > > > This is equivalent to the reordering occurring in the mcslock of > > > librte_eal. > > > > > > Best regards, > > > -Di

Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory

never overwrite the store 2 to > > > > locked, but > > > it does. > > > > To avoid that reordering to happen, one should make the last store > > > > of P1 to > > > have a "release" barrier, ie, STLR. > > > > > > >

Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory

zation of locked should never overwrite the store > > > > > 2 to locked, but > > > > it does. > > > > > To avoid that reordering to happen, one should make the last > > > > > store of P1 to > > > > have a "release" bar

Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory

> > Has anyone investigated later developments in concurrency? > While researching MCS Lock discovered this quote: > https://mfukar.github.io/2017/09/26/mcs.html > Luckily, we don’t have to worry about this very much. MCS locks > right now are mostly a teaching tool, and have mostly

Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory

> > The initialization me->locked=1 in lock() must happen before > next->locked=0 in unlock(), otherwise a thread may hang forever, > waiting me->locked become 0. On weak memory systems (such as ARMv8), > the current implementation allows me->locked=1 to be reordered with > a

Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory

On Mon, 23 Nov 2020 18:29:32 + Honnappa Nagarahalli wrote: > > > > > > The initialization me->locked=1 in lock() must happen before > > next->locked=0 in unlock(), otherwise a thread may hang forever, > > waiting me->locked become 0. On weak memory systems (such as ARMv8), > >

Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory

> > > > > > > > The initialization me->locked=1 in lock() must happen before > > > next->locked=0 in unlock(), otherwise a thread may hang forever, > > > waiting me->locked become 0. On weak memory systems (such as > ARMv8), > > > the current implementation allows me->locked=1 to

Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory

: Wednesday, November 25, 2020 5:51 AM To: Stephen Hemminger Cc: Diogo Behrens ; tho...@monjalon.net; david.march...@redhat.com; dev@dpdk.org; nd ; Honnappa Nagarahalli ; nd Subject: RE: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory > > > > > > > > The ini

Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory

> > The initialization me->locked=1 in lock() must happen before > > next->locked=0 in unlock(), otherwise a thread may hang forever, > > waiting me->locked become 0. On weak memory systems (such as ARMv8), > > the current implementation allows me->locked=1 to be reordered with > >

Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory

31/08/2020 20:45, Honnappa Nagarahalli: > > Hi Diogo, > > Thanks for your explanation. > > As documented in https://developer.arm.com/documentation/ddi0487/fc B2.9.5 > Load-Exclusive and Store-Exclusive instruction usage restrictions: > " Between the Load-Exclusive and the Store-Exclusive, the

Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory

al Message- From: Thomas Monjalon [mailto:tho...@monjalon.net] Sent: Tuesday, October 6, 2020 11:50 PM To: Phil Yang ; Diogo Behrens ; Honnappa Nagarahalli Cc: dev@dpdk.org; nd Subject: Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory 31/08/2020 20:45, Honnappa Nagarahalli: >