[all-commits] [llvm/llvm-project] 7ec308: tsan: prevent pathological slowdown for spurious r...

[Dmitry Vyukov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 7ec308715c6ec0d07e62f7b2f8503cccacf9e96e
      https://github.com/llvm/llvm-project/commit/7ec308715c6ec0d07e62f7b2f8503cccacf9e96e
  Author: Dmitry Vyukov <dvyukov at google.com>
  Date:   2022-07-25 (Mon, 25 Jul 2022)

  Changed paths:
    M compiler-rt/lib/tsan/rtl/tsan_rtl.cpp
    M compiler-rt/lib/tsan/rtl/tsan_rtl.h
    M compiler-rt/lib/tsan/rtl/tsan_rtl_access.cpp
    M compiler-rt/lib/tsan/rtl/tsan_rtl_report.cpp
    M compiler-rt/lib/tsan/rtl/tsan_shadow.h

  Log Message:
  -----------
  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