llvm-project/compiler-rt
Dmitry Vyukov 7ec308715c tsan: prevent pathological slowdown for spurious races
Prevent the following pathological behavior:
Since memory access handling is not synchronized with DoReset,
a thread running concurrently with DoReset can leave a bogus shadow value
that will be later falsely detected as a race. For such false races
RestoreStack will return false and we will not report it.
However, consider that a thread leaves a whole lot of such bogus values
and these values are later read by a whole lot of threads.
This will cause massive amounts of ReportRace calls and lots of
serialization. In very pathological cases the resulting slowdown
can be >100x. This is very unlikely, but it was presumably observed
in practice: https://github.com/google/sanitizers/issues/1552
If this happens, previous access sid+epoch will be the same for all of
these false races b/c if the thread will try to increment epoch, it will
notice that DoReset has happened and will stop producing bogus shadow
values. So, last_spurious_race is used to remember the last sid+epoch
for which RestoreStack returned false. Then it is used to filter out
races with the same sid+epoch very early and quickly.
It is of course possible that multiple threads left multiple bogus shadow
values and all of them are read by lots of threads at the same time.
In such case last_spurious_race will only be able to deduplicate a few
races from one thread, then few from another and so on. An alternative
would be to hold an array of such sid+epoch, but we consider such scenario
as even less likely.
Note: this can lead to some rare false negatives as well:
1. When a legit access with the same sid+epoch participates in a race
as the "previous" memory access, it will be wrongly filtered out.
2. When RestoreStack returns false for a legit memory access because it
was already evicted from the thread trace, we will still remember it in
last_spurious_race. Then if there is another racing memory access from
the same thread that happened in the same epoch, but was stored in the
next thread trace part (which is still preserved in the thread trace),
we will also wrongly filter it out while RestoreStack would actually
succeed for that second memory access.

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D130269
2022-07-25 10:40:11 +02:00
..
cmake Port address sanitizer to LoongArch 2022-07-21 11:32:21 +08:00
docs Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all 2021-07-13 15:21:41 +00:00
include [ORC-RT] Make the ORC runtime C API public. 2022-06-16 19:02:23 -07:00
lib tsan: prevent pathological slowdown for spurious races 2022-07-25 10:40:11 +02:00
test tsan: remove tracking of racy addresses 2022-07-25 10:33:26 +02:00
tools [GWP-ASan] Add inbuilt options parser. 2021-01-15 12:57:05 -08:00
unittests [Sanitizer][Darwin] Cleanup MaybeReexec() function and usage 2022-07-08 14:31:42 -07:00
utils [compiler-rt] NFC: Fix trivial typo 2021-09-04 14:12:58 +05:30
www Remove references to old mailing lists that have moved to discourse. Replace with links to discourse. 2022-07-22 09:59:03 -07:00
.clang-tidy NFC: .clang-tidy: Inherit configs from parents to improve maintainability 2021-06-08 08:25:59 -07:00
.gitignore
CMakeLists.txt [compiler-rt][CMake] Set --unwindlib=none when using LLVM libunwind 2022-07-15 07:25:38 +00:00
CODE_OWNERS.TXT CODE_OWNERS: update information for builtins 2022-04-25 15:36:52 +00:00
CREDITS.TXT
LICENSE.TXT
README.txt

README.txt

Compiler-RT
================================

This directory and its subdirectories contain source code for the compiler
support routines.

Compiler-RT is open source software. You may freely distribute it under the
terms of the license agreement found in LICENSE.txt.

================================