Date: Sun, 26 Feb 2017 12:48:07 +0300 From: Леонид Юрьев <leo@...iev.ru> To: musl@...ts.openwall.com Subject: ldso pthread finalization Hi, In glibc there are a couple of problems. I do not know whether they are relevant for Musl. However, I think should pay attention. So, please take in accound two glibc bugs: 1) pthread_key_delete() race with thread finalization. A race condition could occur between the pthread_key_delete() and the __nptl_deallocate_tsd(). For instance, __nptl_deallocate_tsd() could call a destructor for the key, immediately before the pthread_key_delete() invalidates it (from an another thread), and will continue destructor execution after the completion of pthread_key_delete(). >From a user code this looks as if the corresponding destructor executes after the key has been removed by pthread_key_delete(), and there is no way to know whether was destructor called/executed or not. Suggest add pthread_rwlock_rdlock() for __nptl_deallocate_tsd() and pthread_rwlock_wrlock() for pthread_key_delete(). == https://sourceware.org/bugzilla/show_bug.cgi?id=21031 2) pthread_key_create() destructors and segfault after a DSO unloading. The pthread_key_create() and __nptl_deallocate_tsd() do not track the references to destructor's DSO like the __cxa_thread_atexit_impl(). Therefore the DSO, which holds a destructor's code, could be unloaded before destructor execution or before deleting a corresponding key. So in a complex environment there is no way to know whether it is safe to unload a particular DSO or some tls-destructors are still left. Suggest this should be fixed or documented, e.g. that the pthread_create_key() with a destructor should not be used from lib.so. == https://sourceware.org/bugzilla/show_bug.cgi?id=21032 Regards, Leonid.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.