[all-commits] [llvm/llvm-project] 3056cc: tsan: fix deadlock/crash in signal handling

[Dmitry Vyukov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 3056ccdbae7c36e4eaa2ac89bc82d9c94bddd77a
      https://github.com/llvm/llvm-project/commit/3056ccdbae7c36e4eaa2ac89bc82d9c94bddd77a
  Author: Dmitry Vyukov <dvyukov at google.com>
  Date:   2022-09-30 (Fri, 30 Sep 2022)

  Changed paths:
    M compiler-rt/lib/tsan/rtl/tsan_interceptors.h
    M compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp
    M compiler-rt/lib/tsan/rtl/tsan_rtl.h
    A compiler-rt/test/tsan/signal_thread2.cpp

  Log Message:
  -----------
  tsan: fix deadlock/crash in signal handling

We set in_blocking_func around some blocking C functions so that we don't
delay signal infinitely (if in_blocking_func is set we deliver signals
synchronously).

However, pthread_join is blocking but also call munmap/free to free thread
resources. If we are inside the munmap/free interceptors called from
pthread_join and deliver a signal synchronously, it can lead to deadlocks
and crashes since we re-enter runtime and try to lock the same mutexes
or use the same per-thread data structures.

If we re-enter runtime via an interceptor when in_blocking_func is set,
temporary reset in_blocking_func around the interceptor and restore it back
when we return from the recursive interceptor.

Also move in_blocking_func from ThreadSignalContext to ThreadContext
so that we can CHECK that it's not set in SlotLocker ctor.

Fixes https://github.com/google/sanitizers/issues/1540

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D127845