[PATCH] D72364: [scudo][standalone] Modify malloc_{enable,disable} wrt fork

[Evgenii Stepanov via Phabricator via llvm-commits]

eugenis added a comment.

I see. I think the other approach could be safer. Grab all the locks before fork and release them after fork. This will also allow user applications to use malloc after fork, which ex. glibc allocator supports.



================
Comment at: compiler-rt/lib/scudo/standalone/wrappers_c.inc:163
+  scudo::ScopedLock L(SCUDO_PREFIX(Mutex));
+  if (SCUDO_PREFIX(Disabled))
+    return;
----------------
hctim wrote:
> cryptoad wrote:
> > hctim wrote:
> > > Just to clarify, this is non-racy because malloc_enable and malloc_disable are always called in a single-threaded context? libmemunreachable I know `PTRACE_INTERRUPT`'s the other threads, but unsure about other uses of malloc_enable.
> > I don't think this can be racey since we are protecting the blocks with the mutex. Concurrent call to enable & disable should be resolved appropriately, as well as concurrent calls to the same API since we check for `Disabled` at the beginning of the block.
> Oops, early morning code reviews are a bad idea. You're right.
This will deadlock is malloc_disable or malloc_enable is called concurrently with fork().
The child process will have SCUDO_PREFIX(Mutex) locked with no way to release it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72364