From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11085 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: ldso pthread finalization Date: Sun, 26 Feb 2017 12:41:07 +0100 Message-ID: <20170226114106.GS12395@port70.net> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1488109284 6126 195.159.176.226 (26 Feb 2017 11:41:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Feb 2017 11:41:24 +0000 (UTC) User-Agent: Mutt/1.6.0 (2016-04-01) Cc: musl@lists.openwall.com To: ???????????? ?????????? Original-X-From: musl-return-11100-gllmg-musl=m.gmane.org@lists.openwall.com Sun Feb 26 12:41:19 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1chxCY-0000wm-Fh for gllmg-musl@m.gmane.org; Sun, 26 Feb 2017 12:41:18 +0100 Original-Received: (qmail 22152 invoked by uid 550); 26 Feb 2017 11:41:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 22134 invoked from network); 26 Feb 2017 11:41:19 -0000 Mail-Followup-To: ???????????? ?????????? , musl@lists.openwall.com Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:11085 Archived-At: * ???????????? ?????????? [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.