Fix a memory order issue with weakly ordered systems

this adds a dummy atomic release operation to update_qp, which
should make sure that the new value of reader_idx is visible in
get_hold_current_qp, directly after incrementing the users count.

Fixes: #26875
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26964)

(cherry picked from commit 4a1a7fe5ce088964010779e1f5a90560903ecc76)

diff --git a/crypto/threads_pthread.c b/crypto/threads_pthread.c
index c0598c5a616d5d2226b4085fbbb4d243dacae393..f69b3d6f456700751be11c9fbc7b5b80f06e2a19 100644 (file)
--- a/crypto/threads_pthread.c
+++ b/crypto/threads_pthread.c
@@ -407,6 +407,13 @@ static struct rcu_qp *update_qp(CRYPTO_RCU_LOCK *lock, uint32_t *curr_id)
     ATOMIC_STORE_N(uint32_t, &lock->reader_idx, lock->current_alloc_idx,
                    __ATOMIC_RELAXED);
 
+    /*
+     * this should make sure that the new value of reader_idx is visible in
+     * get_hold_current_qp, directly after incrementing the users count
+     */
+    ATOMIC_ADD_FETCH(&lock->qp_group[current_idx].users, (uint64_t)0,
+                     __ATOMIC_RELEASE);
+
     /* wake up any waiters */
     pthread_cond_signal(&lock->alloc_signal);
     pthread_mutex_unlock(&lock->alloc_lock);