]> git.ipfire.org Git - thirdparty/openldap.git/commitdiff
Flush cache before calling dispose()
authorOndřej Kuzník <okuznik@symas.com>
Thu, 16 Jan 2020 15:00:59 +0000 (15:00 +0000)
committerOndřej Kuzník <okuznik@symas.com>
Tue, 17 Nov 2020 17:58:15 +0000 (17:58 +0000)
This needs to be confirmed:
Location based atomics do not imply a full fence of the same level. So
to get the code in dispose() read the actual data, it seems we need to
initiate a fence.

servers/lloadd/epoch.c

index 50f285ee95501655e6d08836b0cab8acca41c780..4977860f505b38955acc7e4eb2b091a23debf896 100644 (file)
@@ -210,6 +210,25 @@ epoch_leave( epoch_t epoch )
      */
     ldap_pvt_thread_rdwr_runlock( &epoch_mutex );
 
+    /*
+     * Trigger a memory-independent read fence to make sure we're reading the
+     * state after all threads actually finished - which might have happened
+     * after we acquired epoch_mutex so ldap_pvt_thread_rdwr_rlock would not
+     * catch everything.
+     *
+     * TODO is to confirm the below:
+     * It might be that the tests and exchanges above only enforce a fence for
+     * the locations affected, so we could still read stale memory for
+     * unrelated locations? At least that's the only explanation I've been able
+     * to establish for repeated crashes that seem to have gone away with this
+     * in place.
+     *
+     * But then that's contrary to the second example in Acquire/Release
+     * section here:
+     * https://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync
+     */
+    __atomic_thread_fence( __ATOMIC_ACQUIRE );
+
     for ( p = old_refs; p; p = next ) {
         next = p->next;