Skip to content
Snippets Groups Projects
  1. Jan 29, 2020
  2. Jan 17, 2020
  3. Jan 16, 2020
  4. Jan 15, 2020
  5. Jan 14, 2020
    • Marcin Ślusarz's avatar
    • Oksana Sałyk's avatar
      common: fix noisy tests · 7ad6b84b
      Oksana Sałyk authored
      Ref: pmem/pmdk/issues/4231
      7ad6b84b
    • Marcin Ślusarz's avatar
      Merge pull request #4415 from pbalcer/obj-1-5-palloc-race · 4802b70d
      Marcin Ślusarz authored
      obj: fix lock release order in palloc publish
      4802b70d
    • Piotr Balcer's avatar
      obj: fix lock release order in palloc publish · 44d47bbc
      Piotr Balcer authored
      Given a following (sorted) collection of heap actions on
      memory blocks 1, 2:
      
      Alloc 1.1, Alloc 1.2, Free 1.3, Free 2.2, Free 2.5
      
      The algorithm looks at every action and acquires lock
      for that memory block if that lock wasn't acquired previously.
      In this example, two locks would be acquired (2 blocks).
      
      After this is done, the actions are processed. Next,
      the actions are iterated over again, in the exact same order,
      and an "on_process" callback is invoked and the lock for
      that action is dropped.
      
      And this was the problem. The locks were being dropped before all
      actions for the same memory block had their "on_process" callback
      invoked.
      
      In this example, the order of operations would be:
      
      lock(m.1);
      lock(m.2);
      
      process_actions();
      
      on_process(1.1);
      unlock(m.1);
      on_process(1.2);
      on_process(1.3);
      on_process(2.2);
      unlock(m.2);
      on_process(2.5);
      
      This left some of the on_process() callbacks unprotected, leading
      to unintended races.
      
      This patch fixes the problem by unlocking on last block.
      Now, the order of operations will be:
      
      lock(m.1);
      lock(m.2);
      
      process_actions();
      
      on_process(1.1);
      on_process(1.2);
      on_process(1.3);
      unlock(m.1);
      on_process(2.2);
      on_process(2.5);
      unlock(m.2);
      
      This bug triggered an ASSERT() in debug builds, and in release
      builds it might have made runtime calculations related to recycler
      inaccurate, possibliy negatively impacting fragmentation.
      44d47bbc
  6. Jan 13, 2020
  7. Jan 10, 2020
  8. Jan 09, 2020
  9. Nov 29, 2019
  10. Nov 27, 2019
    • Piotr Balcer's avatar
      obj: fix transient redo log of more than 64 entries · 7b1aa3f4
      Piotr Balcer authored
      All transient actions in a single memory operation after 64th
      weren't being applied correctly because the non-cached capacity
      of a transient ulog wasn't being updated alongside the cached
      capacity - this caused a problem where the vast majority of
      code used the cached version, but the actual applying method
      used the uncached one.
      
      The only public API that could conceivably trigger this is
      pmemobj_set_value when used on volatile variables.
      7b1aa3f4
  11. Nov 25, 2019
  12. Nov 21, 2019
  13. Nov 05, 2019
  14. Oct 21, 2019
  15. Oct 18, 2019
  16. Oct 17, 2019
  17. Oct 10, 2019
  18. Oct 08, 2019
Loading