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.3 required=5.0 tests=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 7427 invoked from network); 28 Sep 2020 23:38:16 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 28 Sep 2020 23:38:16 -0000 Received: (qmail 6057 invoked by uid 550); 28 Sep 2020 23:38:12 -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 6032 invoked from network); 28 Sep 2020 23:38:11 -0000 Date: Mon, 28 Sep 2020 19:37:59 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200928233758.GB17637@brightrain.aerifal.cx> References: <20200928232614.GA17637@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3lcZGd9BuhuYXNfi" Content-Disposition: inline In-Reply-To: <20200928232614.GA17637@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Pending patches for MT-fork stuff --3lcZGd9BuhuYXNfi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Sep 28, 2020 at 07:26:15PM -0400, Rich Felker wrote: > In investigating the MT-fork deadlock stuff and working on a patch > that makes it attempt to trap rather than deadlocking, I found a > problem with interaction of fork and aio. A fix for that, along with > the patch to trap, and a minimal testcase for the aio bug, are > attached. > > There's also a problematic interaction of abort with fork that was > just found in glibc that also exists in musl, that I still need to > fix. I'll follow up later with a proposed solution for that. And here's the proposed abort fix. --3lcZGd9BuhuYXNfi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="0004-move-__abort_lock-to-its-own-file-and-drop-pointless.patch" >From 000b86dffecf68c1f479e532dcf4e9a403062521 Mon Sep 17 00:00:00 2001 From: Rich Felker Date: Mon, 28 Sep 2020 19:30:19 -0400 Subject: [PATCH 4/5] move __abort_lock to its own file and drop pointless weak_alias trick the dummy definition of __abort_lock in sigaction.c was performing exactly the same role that putting the lock in its own source file could and should have been used to achieve. while we're moving it, give it a proper declaration. --- src/exit/abort.c | 2 -- src/exit/abort_lock.c | 3 +++ src/internal/pthread_impl.h | 2 ++ src/signal/sigaction.c | 6 ------ 4 files changed, 5 insertions(+), 8 deletions(-) create mode 100644 src/exit/abort_lock.c diff --git a/src/exit/abort.c b/src/exit/abort.c index e1980f10..f21f458e 100644 --- a/src/exit/abort.c +++ b/src/exit/abort.c @@ -6,8 +6,6 @@ #include "lock.h" #include "ksigaction.h" -hidden volatile int __abort_lock[1]; - _Noreturn void abort(void) { raise(SIGABRT); diff --git a/src/exit/abort_lock.c b/src/exit/abort_lock.c new file mode 100644 index 00000000..3af72c7b --- /dev/null +++ b/src/exit/abort_lock.c @@ -0,0 +1,3 @@ +#include "pthread_impl.h" + +volatile int __abort_lock[1]; diff --git a/src/internal/pthread_impl.h b/src/internal/pthread_impl.h index 23ee566c..21d51be6 100644 --- a/src/internal/pthread_impl.h +++ b/src/internal/pthread_impl.h @@ -197,6 +197,8 @@ hidden void __tl_sync(pthread_t); extern hidden volatile int __thread_list_lock; +extern hidden volatile int __abort_lock[1]; + extern hidden unsigned __default_stacksize; extern hidden unsigned __default_guardsize; diff --git a/src/signal/sigaction.c b/src/signal/sigaction.c index c109bea0..a4737404 100644 --- a/src/signal/sigaction.c +++ b/src/signal/sigaction.c @@ -7,12 +7,6 @@ #include "lock.h" #include "ksigaction.h" -static volatile int dummy_lock[1] = { 0 }; - -extern hidden volatile int __abort_lock[1]; - -weak_alias(dummy_lock, __abort_lock); - static int unmask_done; static unsigned long handler_set[_NSIG/(8*sizeof(long))]; -- 2.21.0 --3lcZGd9BuhuYXNfi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="0005-fix-race-deadlock-with-abort-in-forked-child-of-mult.patch" >From 7e661e4ff9f70b625e496b54729943bf3f7ecfac Mon Sep 17 00:00:00 2001 From: Rich Felker Date: Mon, 28 Sep 2020 19:32:34 -0400 Subject: [PATCH 5/5] fix race deadlock with abort in forked child of multithreaded parent if the multithreaded parent forked while another thread was calling sigaction for SIGABRT or calling abort, the child could inherit a lock state in which future calls to abort will deadlock. this is nonconforming since abort is AS-safe and permitted to be called in the MT-forked child. since there is no userspace data state protected by the lock (it's only used to exclude sigaction for SIGABRT while abort is in progress), just reset the lock word to 0 in the child rather than holding the lock across the fork. --- src/process/fork.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/process/fork.c b/src/process/fork.c index 538a0bcb..b5a5fa11 100644 --- a/src/process/fork.c +++ b/src/process/fork.c @@ -33,6 +33,7 @@ pid_t fork(void) __thread_list_lock = 0; libc.threads_minus_1 = 0; if (libc.need_locks > 0) libc.need_locks = -2; + *__abort_lock = 0; } __aio_atfork(!ret); __restore_sigs(&set); -- 2.21.0 --3lcZGd9BuhuYXNfi--