ldso pthread finalization

["Леонид Юрьев" <leo@yuriev.ru>]

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.