[all-commits] [llvm/llvm-project] 97b4e6: tsan: fix false positives in dynamic libs with sta...

[Dmitry Vyukov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 97b4e631173a5f2f1f79361f9fc56c8f85681f73
      https://github.com/llvm/llvm-project/commit/97b4e631173a5f2f1f79361f9fc56c8f85681f73
  Author: Dmitry Vyukov <dvyukov at google.com>
  Date:   2021-12-02 (Thu, 02 Dec 2021)

  Changed paths:
    M compiler-rt/lib/asan/asan_interceptors.cpp
    M compiler-rt/lib/memprof/memprof_interceptors.cpp
    M compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc
    M compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp
    A compiler-rt/test/tsan/Linux/dlopen_static_tls.cpp

  Log Message:
  -----------
  tsan: fix false positives in dynamic libs with static tls

The added test demonstrates  loading a dynamic library with static TLS.
Such static TLS is a hack that allows a dynamic library to have faster TLS,
but it can be loaded only iff all threads happened to allocate some excess
of static TLS space for whatever reason. If it's not the case loading fails with:

dlopen: cannot load any more object with static TLS

We used to produce a false positive because dlopen will write into TLS
of all existing threads to initialize/zero TLS region for the loaded library.
And this appears to be racing with initialization of TLS in the thread
since we model a write into the whole static TLS region (we don't what part
of it is currently unused):

WARNING: ThreadSanitizer: data race (pid=2317365)
  Write of size 1 at 0x7f1fa9bfcdd7 by main thread:
    0 memset
    1 init_one_static_tls
    2 __pthread_init_static_tls
    [[ this is where main calls dlopen ]]
    3 main
  Previous write of size 8 at 0x7f1fa9bfcdd0 by thread T1:
    0 __tsan_tls_initialization

Fix this by ignoring accesses during dlopen.

Reviewed By: melver

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