[PATCH] D26028: [asan/lsan] Avoid possible deadlock in dynamic ASan runtime thread initialization.

[Maxim Ostapenko via llvm-commits]

m.ostapenko created this revision.
m.ostapenko added reviewers: kcc, dvyukov, eugenis.
m.ostapenko added subscribers: llvm-commits, ygribov.
m.ostapenko set the repository for this revision to rL LLVM.
m.ostapenko added a project: Sanitizers.
Herald added subscribers: kubabrecka, srhines, danalbert, tberghammer.

As was reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982, there is possible deadlock in dynamic ASan runtime when we dlopen() shared lib which creates a thread at the global initialization stage. Here is the scenario:

1. dlopen grabs a __GI___pthread_mutex_lock in main thread.
2. main thread calls pthread_create, ASan intercepts it, calls real pthread_create and waits for the second thread to be "fully initialized".
3. Newly created thread tries to access a thread local **disable_counter** in LSan (to complete its "full initialization") and hangs in **tls_get_addr_tail**, because it also tries to acquire __GI___pthread_mutex_lock.

The issue doesn't reproduce on older Glibc (e.g. 2.19 on my Ubuntu box) because tls_get_addr_tail doesn't try to acquire __GI___pthread_mutex_lock there, but reproducible on more recent ones, e.g. Glibc 2.23.

The deadlock doesn't occur with ASan static linkage because in this case **disable_counter** resides in static tls, thus **tls_get_addr_tail** isn't called.

The simple fix would be just using **__attribute__((tls_model("initial-exec")))** for **disable_counter** in LSan. This should be fine since nobody would dlopen {A, L}San runtime in any case.


Repository:
  rL LLVM

https://reviews.llvm.org/D26028

Files:
  lib/lsan/lsan_common.cc
  test/asan/TestCases/Linux/pthread_create_from_constructor.cc


Index: test/asan/TestCases/Linux/pthread_create_from_constructor.cc
===================================================================
--- /dev/null
+++ test/asan/TestCases/Linux/pthread_create_from_constructor.cc
@@ -0,0 +1,48 @@
+// Test that ASan doesn't deadlock in __interceptor_pthread_create called
+// from dlopened shared library constructor. The deadlock happens only in shared
+// ASan runtime with recent Glibc (2.23 fits) when __interceptor_pthread_create
+// grabs global Glibc's GL(dl_load_lock) and waits for tls_get_addr_tail that
+// also tries to acquire it.
+//
+// RUN: %clangxx_asan -DBUILD_SO=1 -fPIC -shared %s -o %t-so.so
+// RUN: %clangxx_asan %s -o %t
+// RUN: %run %t 2>&1
+
+// dlopen() can not be intercepted on Android
+// UNSUPPORTED: android
+
+#ifdef BUILD_SO
+
+#include <stdio.h>
+#include <pthread.h>
+#include <unistd.h>
+
+void *threadFn(void *) {
+  fprintf(stderr, "thread started\n");
+  while (true) {
+    usleep(100000);
+  }
+  return 0;
+}
+
+void __attribute__((constructor)) startPolling() {
+  fprintf(stderr, "initializing library\n");
+  pthread_t t;
+  pthread_create(&t, 0, &threadFn, 0);
+  fprintf(stderr, "done\n");
+}
+
+#else
+
+#include <dlfcn.h>
+#include <stdlib.h>
+#include <string>
+
+int main(int argc, char **argv) {
+  std::string path = std::string(argv[0]) + "-so.so";
+  void *handle = dlopen(path.c_str(), RTLD_LAZY);
+  if (!handle)
+    abort();
+  return 0;
+}
+#endif
Index: lib/lsan/lsan_common.cc
===================================================================
--- lib/lsan/lsan_common.cc
+++ lib/lsan/lsan_common.cc
@@ -32,6 +32,7 @@
 // also to protect the global list of root regions.
 BlockingMutex global_mutex(LINKER_INITIALIZED);
 
+__attribute__((tls_model("initial-exec")))
 THREADLOCAL int disable_counter;
 bool DisabledInThisThread() { return disable_counter > 0; }
 void DisableInThisThread() { disable_counter++; }


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D26028.76006.patch
Type: text/x-patch
Size: 1912 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161027/5f491b65/attachment.bin>