[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 26 Feb 2017 12:41:07 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: ???????????? ?????????? <leo@...iev.ru>
Cc: musl@...ts.openwall.com
Subject: Re: ldso pthread finalization
* ???????????? ?????????? <leo@...iev.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.
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.
