1. 13 Feb, 2020 2 commits
  2. 12 Feb, 2020 15 commits
  3. 11 Feb, 2020 6 commits
    • Ondřej Surý's avatar
      Merge branch '1428-possible-data-race-in-rbtdb-happens-occasionally-on-ppc64le-v9_14' into 'v9_14' · 12b44788
      Ondřej Surý authored
      Resolve "Possible data race in rbtdb, happens occasionally on ppc64le"
      
      See merge request !3035
      12b44788
    • Ondřej Surý's avatar
      Convert all atomic operations in isc_rwlock to release-acquire memory ordering · 3c8a441a
      Ondřej Surý authored
      The memory ordering in the rwlock was all wrong, I am copying excerpts
      from the https://en.cppreference.com/w/c/atomic/memory_order#Relaxed_ordering
      for the convenience of the reader:
      
        Relaxed ordering
      
        Atomic operations tagged memory_order_relaxed are not synchronization
        operations; they do not impose an order among concurrent memory
        accesses. They only guarantee atomicity and modification order
        consistency.
      
        Release-Acquire ordering
      
        If an atomic store in thread A is tagged memory_order_release and an
        atomic load in thread B from the same variable is tagged
        memory_order_acquire, all memory writes (non-atomic and relaxed atomic)
        that happened-before the atomic store from the point of view of thread
        A, become visible side-effects in thread B. That is, once the atomic
        load is completed, thread B is guaranteed to see everything thread A
        wrote to memory.
      
        The synchronization is established only between the threads releasing
        and acquiring the same atomic variable. Other threads can see different
        order of memory accesses than either or both of the synchronized
        threads.
      
      Which basically means that we had no or weak synchronization between
      threads using the same variables in the rwlock structure.  There should
      not be a significant performance drop because the critical sections were
      already protected by:
      
        while(1) {
          if (relaxed_atomic_operation) {
            break;
          }
          LOCK(lock);
          if (!relaxed_atomic_operation) {
            WAIT(sem, lock);
          }
          UNLOCK(lock)l
        }
      
      I would add one more thing to "Don't do your own crypto, folks.":
      
        - Also don't do your own locking, folks.
      3c8a441a
    • Ondřej Surý's avatar
      Make isc_rwlock.c thread-safe · 1da0994e
      Ondřej Surý authored
      The ThreadSanitizer found several possible data races in our rwlock
      implementation.  This commit changes all the unprotected variables to atomic and
      also changes the explicit memory ordering (atomic_<foo>_explicit(..., <order>)
      functions to use our convenience macros (atomic_<foo>_<order>).
      1da0994e
    • Ondřej Surý's avatar
      Merge branch 'ondrej/remove-OpenSSL-engine-specification-in-label-v9_14' into 'v9_14' · 50058a4b
      Ondřej Surý authored
      [v9_14] Cleanup support for specifying PKCS#11 engine as part of the label
      
      See merge request !3033
      50058a4b
    • Ondřej Surý's avatar
      Remove reference to prepending label with engine in manpage · f172ecab
      Ondřej Surý authored
      (cherry picked from commit 33fa3d5e)
      f172ecab
    • Ondřej Surý's avatar
      Cleanup support for specifying PKCS#11 engine as part of the label · 95130a37
      Ondřej Surý authored
      The code for specifying OpenSSL PKCS#11 engine as part of the label
      (e.g. -l "pkcs11:token=..." instead of -E pkcs11 -l "token=...")
      was non-functional.  This commit just cleans the related code.
      
      (cherry picked from commit a5c87d9d)
      95130a37
  4. 10 Feb, 2020 2 commits
  5. 09 Feb, 2020 2 commits
  6. 08 Feb, 2020 4 commits
  7. 07 Feb, 2020 9 commits