From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11083 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?B?0JvQtdC+0L3QuNC0INCu0YDRjNC10LI=?= Newsgroups: gmane.linux.lib.musl.general Subject: ldso pthread finalization Date: Sun, 26 Feb 2017 12:48:07 +0300 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1488102508 4156 195.159.176.226 (26 Feb 2017 09:48:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Feb 2017 09:48:28 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-11098-gllmg-musl=m.gmane.org@lists.openwall.com Sun Feb 26 10:48:23 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 1chvRE-00007O-8Q for gllmg-musl@m.gmane.org; Sun, 26 Feb 2017 10:48:20 +0100 Original-Received: (qmail 15563 invoked by uid 550); 26 Feb 2017 09:48:22 -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 15533 invoked from network); 26 Feb 2017 09:48:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuriev-ru.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Rz272Ncdfiv1DwYuHqTHXKfRMjw99yY3g3SQ5er9pPI=; b=gK3p8NOQtGkuXNG03SHRlZVts3Ug1lHG6T9CJ+6lNYPfuAmU0C91BpfJNCsabnbFhe CUfixf/zKpTImS0pbmDK1TqhY8D+hDUFrwHTTwMvx4hNH15/wLmqG66XCHZOzEzXnOxn GNEcVzqgYv8nvFQbeooQReafN07rKKPWAFUGaxQKSUrrhe40/SV+rP+KoqgntS8eV1wI JR1YG1cOKrAzxCWD185r2JcXnzwXWVico8PiZPqO7vGl+Pbji+2OY9EwiXCI9uM6V3yM S1S/nYgkEZzhiO2mx6lRtCD4i3bdaes3fibwnTAmd1xZUPQSXQRjoabIzlsIzTp41vJ2 Zzsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Rz272Ncdfiv1DwYuHqTHXKfRMjw99yY3g3SQ5er9pPI=; b=ThDVstin/2jxFLOP/fuxbAC/fm9nOIxXBVQVrNooMw/gy+lHzf4C4c+15ArWB9QTXt 1AzxxLKoqB7fBqChAMo/wvKujreEu2RTKbQyzFNiuCmuvRfNtkfhnBJ2QXx/uxOLhsTm ozAWec+8onUyAfQR57ndPuGBPHNWyLv2mQCtuWXfYt3IG75zzgsWZSgWT7fzz9MNi1+x wATyXf2bqdUAjwQT9MP83TEmJnW4IVurLzUAryCJa6yMNu2u2c0m+Pcz/h8ZJFW491uG sxeWOxp9qDR2IwuTBAby9RPjBfTy/yINn4UTg2zQHgw4mqWXHt0QdMR27aXyQpVAQHJB 2jlQ== X-Gm-Message-State: AMke39l/5r8yQNrjOhvkfW7Ab8h8p877OSRXuC4FW4u/Cze3QpWnytbD9RsorMG+chsc/clXCNZKCMYb5Y7cFw== X-Received: by 10.37.199.204 with SMTP id w195mr1717930ybe.4.1488102487443; Sun, 26 Feb 2017 01:48:07 -0800 (PST) Xref: news.gmane.org gmane.linux.lib.musl.general:11083 Archived-At: 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.