diff options
author | Dmitry Vyukov <dvyukov@google.com> | 2021-04-30 08:32:52 +0200 |
---|---|---|
committer | Dmitry Vyukov <dvyukov@google.com> | 2021-04-30 08:48:20 +0200 |
commit | ed7bf7d73fa253c770c0e715db5262f359268c3a (patch) | |
tree | e72c8e4a50e6dc5eb73230a7467e7956a234fc74 /llvm/lib/Support/GraphWriter.cpp | |
parent | b535459d0a1db37fca6688b8e15305e361debff5 (diff) | |
download | llvm-ed7bf7d73fa253c770c0e715db5262f359268c3a.zip llvm-ed7bf7d73fa253c770c0e715db5262f359268c3a.tar.gz llvm-ed7bf7d73fa253c770c0e715db5262f359268c3a.tar.bz2 |
tsan: refactor fork handling
Commit efd254b6362 ("tsan: fix deadlock in pthread_atfork callbacks")
fixed another deadlock related to atfork handling.
But builders with DCHECKs enabled reported failures of
pthread_atfork_deadlock2.c and pthread_atfork_deadlock3.c tests
related to the fact that we hold runtime locks on interceptor exit:
https://lab.llvm.org/buildbot/#/builders/70/builds/6727
This issue is somewhat inherent to the current approach,
we indeed execute user code (atfork callbacks) with runtime lock held.
Refactor fork handling to not run user code (atfork callbacks)
with runtime locks held. This change does this by installing
own atfork callbacks during runtime initialization.
Atfork callbacks run in LIFO order, so the expectation is that
our callbacks run last, right before the actual fork.
This way we lock runtime mutexes around fork, but not around
user callbacks.
Extend tests to also install after fork callbacks just to cover
more scenarios. Some tests also started reporting real races
that we previously suppressed.
Also extend tests to cover fork syscall support.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D101517
Diffstat (limited to 'llvm/lib/Support/GraphWriter.cpp')
0 files changed, 0 insertions, 0 deletions