From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16008 invoked from network); 23 Nov 2020 11:46:12 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 23 Nov 2020 11:46:12 -0000 Received: (qmail 5960 invoked by uid 550); 23 Nov 2020 11:46:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1966 invoked from network); 23 Nov 2020 11:41:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606131692; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sv+jsG1ATWR5z511i/7iT3AxnjN0duUReuOPu6++t9g=; b=eyauuvsRV14kA+O3fo5eVA4Z9qjOAoLoyPKAJJ6tM8xT7ExksIHqDEjLMcoz+qNI9SpfYN 5+L8LPMOH9WDXU3eZY3YCopvEIN9ipZqXHkm/DBYYfxyFqgytKh8wEJdTuZQFVJ5ZniZ4L h/DIGnyi/mYqX5AnvvXVyAU/faNTAQo= X-MC-Unique: 35cIPjX2O72r7lfxNM3V0Q-1 Date: Mon, 23 Nov 2020 11:41:24 +0000 From: Jonathan Wakely To: Rich Felker Cc: Florian Weimer , =?utf-8?B?0JDRgNGB0LXQvdC40Lk=?= , musl@lists.openwall.com Message-ID: <20201123114124.GP1312820@redhat.com> References: <1605849917.737458858@f540.i.mail.ru> <1605941217.735966206@f110.i.mail.ru> <20201121155128.GN534@brightrain.aerifal.cx> <1606070615.957905591@f395.i.mail.ru> <20201122191106.GO534@brightrain.aerifal.cx> <87mtz99owk.fsf@mid.deneb.enyo.de> <20201122192824.GQ534@brightrain.aerifal.cx> MIME-Version: 1.0 In-Reply-To: <20201122192824.GQ534@brightrain.aerifal.cx> X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jwakely@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit Subject: Re: [musl] Mutexes are not unlocking On 22/11/20 14:28 -0500, Rich Felker wrote: >On Sun, Nov 22, 2020 at 08:23:23PM +0100, Florian Weimer wrote: >> * Rich Felker: >> >> > On Sun, Nov 22, 2020 at 09:43:35PM +0300, Арсений wrote: >> >> >> >> Hello, >> >> The problem is that mutex is not got unlocked after the first unlock(). >> >>   >> >> libstdc++ uses a wrapper for pthread called gthreads. This wrapper >> >> checks for the state of the mutex system. For >> >> example, pthread_mutex_unlock() is called in a following way: >> >>   >> >> static inline int >> >> __gthread_mutex_unlock (__gthread_mutex_t *__mutex) >> >> { >> >> if (__gthread_active_p ()) >> >> return __gthrw_(pthread_mutex_unlock) (__mutex); >> >> else >> >> return 0; >> >> } >> > >> > Yes. This code is invalid (it misinterprets weak symbol information to >> > draw incorrect conclusions about whether threads may be in use) and >> > thus is disabled in builds of gcc/libstdc++ targeting musl-based >> > systems. GCC and glibc-based distro folks mostly don't care because >> > it only breaks static linking, but some of them actually hack gcc's >> > libpthread.a into one giant .o file to work around the problem rather >> > than fixing this in gcc... >> >> GCC 11 has a fix (if used along with glibc 2.32), but I wonder if it's The GCC 11 change isn't used for mutexes. I use __libc_single_threaded for deciding whether to use atomics or plain non-atomic ops for ref-count updates. But for actions like mutex locks I don't use it, because it would do the wrong thing for code like: int main() { std::mutex m; std::lock_guard l(m); std::thread t( []{} }; t.join(); } In this program __libc_single_threaded is true when we construct the lock_guard, but false when it is destroyed at the end of the block. If we checked __libc_single_threaded for mutex locking/unlocking then we would be inconsistent here, we would elide the lock but try to unlock a mutex that was never locked, which would be UB. Whatever condition we check to decide whether to call the pthreads function needs to give the same result for the lock and unlock. That condition is currently __gthread_active_p, which checks if a symbol is weak. >> going to run into a similar issue because inlined code from older GCC >> versions uses a diverging version of the check. No, everything uses the same check. GCC 11 didn't change anything for mutexes. >> Jonathan, more context is here: >> >> > >Uhg, that's a really nasty problem. Is __gthread_active_p() also >inlined? Or can it be given a definition to mitigate the problem? It's inlined, and making it a non-inline PLT call would negate some of the point of using it (it's there mostly as an optimization). But I don't think inlining it is a problem, because its definition hasn't changed. I think the right thing to do is a new configuration which completely avoids using weak symbols in gthreads, and just calls the pthread symbols directly. A future version of glibc is going to move pthreads symbols into libc anyway: https://sourceware.org/legacy-ml/libc-alpha/2019-10/msg00080.html After that, the __gthread_active_p condition is just a wasted branch, because it will be unconditionally true: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89714 If the musl libstdc++ removes the use of __gthread_active_p, but code compiled against a glibc libstdc++ inlines the __gthread_active_p check, then it seems to me that musl (or the musl libstdc++) needs to ensure that the inlined __gthread_active_p will return true. It can do that by providing a non-weak symbol called __pthread_key_create (the symbol won't be called, it just has to exist).