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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14186 invoked from network); 8 Oct 2022 01:36:31 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 8 Oct 2022 01:36:31 -0000 Received: (qmail 9785 invoked by uid 550); 8 Oct 2022 01:36:28 -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 9747 invoked from network); 8 Oct 2022 01:36:28 -0000 Date: Fri, 7 Oct 2022 21:36:16 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20221008013615.GE29905@brightrain.aerifal.cx> References: <033092a85a52d9f8e8d73a235e2381ae@ispras.ru> <20221006182151.GV29905@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="UoPmpPX/dBe4BELn" Content-Disposition: inline In-Reply-To: <20221006182151.GV29905@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] MT fork and key_lock in pthread_key_create.c --UoPmpPX/dBe4BELn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Oct 06, 2022 at 02:21:51PM -0400, Rich Felker wrote: > On Thu, Oct 06, 2022 at 09:37:50AM +0300, Alexey Izbyshev wrote: > > Hi, > > > > I noticed that fork() doesn't take key_lock that is used to protect > > the global table of thread-specific keys. I couldn't find mentions > > of this lock in the MT fork discussion in the mailing list archive. > > Was this lock overlooked? > > I think what happened was that we made the main list of locks to > review and take care of via grep for LOCK, and then manually added > known instances of locks using other locking primitives. This one must > have been missed. > > Having special-case lock types like this is kinda a pain, but as long > as there aren't too many I guess it's not a big deal. Proposed patch attached. --UoPmpPX/dBe4BELn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pthread_key_fork.diff" diff --git a/src/internal/fork_impl.h b/src/internal/fork_impl.h index ae3a79e5..354e733b 100644 --- a/src/internal/fork_impl.h +++ b/src/internal/fork_impl.h @@ -16,3 +16,4 @@ extern hidden volatile int *const __vmlock_lockptr; hidden void __malloc_atfork(int); hidden void __ldso_atfork(int); +hidden void __pthread_key_atfork(int); diff --git a/src/process/fork.c b/src/process/fork.c index 80e804b1..56f19313 100644 --- a/src/process/fork.c +++ b/src/process/fork.c @@ -37,6 +37,7 @@ static void dummy(int x) { } weak_alias(dummy, __fork_handler); weak_alias(dummy, __malloc_atfork); weak_alias(dummy, __aio_atfork); +weak_alias(dummy, __pthread_key_atfork); weak_alias(dummy, __ldso_atfork); static void dummy_0(void) { } @@ -51,6 +52,7 @@ pid_t fork(void) int need_locks = libc.need_locks > 0; if (need_locks) { __ldso_atfork(-1); + __pthread_key_atfork(-1); __aio_atfork(-1); __inhibit_ptc(); for (int i=0; i