[PATCH] D60593: [GwpAsan] Introduce GWP-ASan.

[Evgenii Stepanov via Phabricator via llvm-commits]

eugenis added inline comments.


================
Comment at: compiler-rt/lib/scudo/scudo_allocator.cpp:243
+    : Quarantine(LINKER_INITIALIZED) {
+      gwp_asan::options::initOptions();
+      GuardedAlloc.init(*gwp_asan::options::getOptions());
----------------
hctim wrote:
> cryptoad wrote:
> > We are avoiding any non-trivial initialization on static objects. Ideally those 2 would go in `init`.
> So this kind of conflicts with my previous statement. If we move this initialisation into `init()`, we will recurse into `init() -> Allocator::allocate() -> initThreadMaybe() -> init()` and we deadlock on `pthread_once`.
> 
> We have two options here:
> 1. Leave the GwpAsan initialisation in the c'tor, which forces the initialisation of Scudo at startup, rather than lazily initialising.
> 2. We avoid malloc() and instead do our own memory management in GwpAsan's `init()`. 
> 
> @eugenis - What do you think is the right long-term support option for GwpAsan here?
how about
3. Do "fast pass" initialization in init(), then do full initialization on first sampled malloc

"fast pass" initialization is just enough to do sampling, i.e. the inlined part of shouldSample().

Since init() can run in a secondary thread, the access to SampleRate can race and needs to be changed to an atomic.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60593/new/

https://reviews.llvm.org/D60593