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 ARMv8),
    the current implementation allows me->locked=1 to be reordered with
    announcing the node (pred->next=me) and, consequently, to be
    reordered with next->locked=0 in unlock().

    This fix adds a release barrier to pred->next=me, forcing
    me->locked=1 to happen before this operation.

Signed-off-by: Diogo Behrens <redacted>
---
 lib/librte_eal/include/generic/rte_mcslock.h | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/lib/librte_eal/include/generic/rte_mcslock.h

b/lib/librte_eal/include/generic/rte_mcslock.h
index 2bef28351..ce553f547 100644

--- a/lib/librte_eal/include/generic/rte_mcslock.h
+++ b/lib/librte_eal/include/generic/rte_mcslock.h

@@ -68,7 +68,14 @@ rte_mcslock_lock(rte_mcslock_t **msl, rte_mcslock_t

*me)
 		 */
 		return;
 	}
-	__atomic_store_n(&prev->next, me, __ATOMIC_RELAXED);
+	/* The store to me->next above should also complete before the
node is
+	 * visible to predecessor thread releasing the lock. Hence, the store
+	 * prev->next also requires release semantics. Note that, for
example,
+	 * on ARM, the release semantics in the exchange operation is not
+	 * strong as a release fence and is not sufficient to enforce the
+	 * desired order here.