ldso pthread finalization

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.

Re: ldso pthread finalization

[Szabolcs Nagy]

* ???????????? ?????????? <leo@yuriev.ru> [2017-02-26 12:48:07 +0300]:
> 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
> 

i dont think the standard requires that dtors
must finish running when pthread_key_delete
returns: a long running dtor could hold up
pthread_key_delete indefinitely.

if there were a lock, like you suggest, then
the dtor could deadlock when it synchronizes
with other threads doing a pthread_key_delete.

the standard is not very clear, so it is
better to treat it unspecified if dtors
must finish or not.

> 
> 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
> 

the standard even gives this as an example why
there is pthread_key_delete: it's the user's
responsibility to delete keys registered by the
dso before dso unload.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_key_delete.html

one could argue that in c++ unloading a dso with
tls dtors is undefined so you should not rely on
that working either.
(dso tracking logic requires special abi which
a platform may or may not have in place, the
standard does not say anything about this.
in particular the hack that is used to track
the dsos of atexit handlers is non-conforming
so at least dlclose+atexit cannot work the
way you expect on a conforming system.)

in any case, musl is not affected because its
dlclose is a nop.

Re: ldso pthread finalization

[Rich Felker]

On Sun, Feb 26, 2017 at 12:48:07PM +0300, Леонид Юрьев wrote:
> 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().

I consider deletion of a key for which a value is set to be a type of
use-after-free bug and thereby to have undefined behavior. POSIX does
not seem to specify a behavior for it, and it does not seem possible
to specify something consistent. 

> 2) pthread_key_create() destructors and segfault after a DSO unloading.

musl does not unload DSOs, so this one is not relevant to musl.

Rich