[compiler-rt] [scudo] Allow to resize allocation ring buffer (PR #82683)

via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 6 14:47:06 PST 2024


================
@@ -1594,12 +1600,33 @@ class Allocator {
     RB->StackDepotSize = StackDepotSize;
     RB->RawStackDepotMap = DepotMap;
 
-    atomic_store(&RingBufferAddress, reinterpret_cast<uptr>(RB),
-                 memory_order_release);
+    swapOutRingBuffer(RB);
     static_assert(sizeof(AllocationRingBuffer) %
                           alignof(typename AllocationRingBuffer::Entry) ==
                       0,
                   "invalid alignment");
+    return true;
+  }
+
+  void swapOutRingBuffer(AllocationRingBuffer *NewRB) {
+    // To allow resizeRingBuffer to be called in a multi-threaded context by apps,
+    // we do not actually unmap, but only madvise(DONTNEED) the pages. That way,
+    // straggler threads will not crash.
----------------
ChiaHungDuan wrote:

In addition, keeping the old buffer doesn't prevent the potential crash. Any access to the old buffer can cause problem. Like if some thread tries to read the data from the old buffer which has been cleaned. Not to say the DONTNEED may happen at the same time some thread is still accessing it, which seems to be some undefined behavior. 

And yes, the buffer swap is complicated under current design (Thanks for the email BTW). One easy way in my mind is, we only reset the available size of ring buffer and the ring buffer will be initialized with some value is big enough for all of their cases. As a result, in most cases, they still use small memory for the ring buffer. 

I suppose we have the assumption that once we reset the available size, all the writes happened or happening will be viewed as staled (i.e., the buffer contains zero element). This will avoid the need of synchronizing the writing position and the available buffer size. 

I'm not sure if we need to do some changes here and there in Android. What do you think?

https://github.com/llvm/llvm-project/pull/82683


More information about the llvm-commits mailing list