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 5809 invoked from network); 11 Feb 2023 18:35:22 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 11 Feb 2023 18:35:22 -0000 Received: (qmail 21951 invoked by uid 550); 11 Feb 2023 18:35:19 -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 21919 invoked from network); 11 Feb 2023 18:35:18 -0000 Date: Sat, 11 Feb 2023 13:35:06 -0500 From: Rich Felker To: Alexey Izbyshev Cc: musl@lists.openwall.com Message-ID: <20230211183505.GL4163@brightrain.aerifal.cx> References: <20221109104613.48062-1-izbyshev@ispras.ru> <20221214022618.GB15716@brightrain.aerifal.cx> <1a0289c15879bef6d538c0066f58545c@ispras.ru> <20230210162957.GB4163@brightrain.aerifal.cx> <63c0897d647936c946268f5a967a5e4d@ispras.ru> <20230211150603.GI4163@brightrain.aerifal.cx> <20230211171338.GD1903@voyager> <2da3840a9345c0a810e9d93ab4f6bca7@ispras.ru> <20230211175948.GK4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] mq_notify: fix close/recv race on failure path On Sat, Feb 11, 2023 at 09:08:53PM +0300, Alexey Izbyshev wrote: > On 2023-02-11 20:59, Rich Felker wrote: > >On Sat, Feb 11, 2023 at 08:50:15PM +0300, Alexey Izbyshev wrote: > >>On 2023-02-11 20:13, Markus Wichmann wrote: > >>>On Sat, Feb 11, 2023 at 10:06:03AM -0500, Rich Felker wrote: > >>>>--- a/src/thread/pthread_detach.c > >>>>+++ b/src/thread/pthread_detach.c > >>>>@@ -5,8 +5,12 @@ static int __pthread_detach(pthread_t t) > >>>> { > >>>> /* If the cas fails, detach state is either already-detached > >>>> * or exiting/exited, and pthread_join will trap or cleanup. */ > >>>>- if (a_cas(&t->detach_state, DT_JOINABLE, DT_DETACHED) != > >>>>DT_JOINABLE) > >>>>+ if (a_cas(&t->detach_state, DT_JOINABLE, DT_DETACHED) != > >>>>DT_JOINABLE) { > >>>>+ int cs; > >>>>+ __pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &cs); > >>>> return __pthread_join(t, 0); > >>> ^^^^^^ I think you forgot to rework this. > >>>>+ __pthread_setcancelstate(cs, 0); > >>>>+ } > >>>> return 0; > >>>> } > >>>> > >>> > >>>I see no other obvious missteps, though. > >>> > >>Same here, apart from this and misspelled "pthred_detach" in the > >>commit message, the patches look good to me. > >> > >>Regarding the POSIX requirement to run sigev_notify_function in the > >>context of a detached thread, while it's possible to observe the > >>wrong detachstate for a short while via pthread_getattr_np after > >>these patches, I'm not sure there is a standard way to do that. Even > >>if it exists, this minor issue may be not worth caring about. > > > >Would this just be if the notification callback executes before > >mq_notify returns in the parent? > > Yes, it seems so. > > >I suppose we could have the newly > >created thread do the work of making the syscall, handling the error > >case, detaching itself on success and and reporting back to the > >mq_notify function whether it succeeded or failed via the > >semaphore/args structure. Thoughts on that? > > > Could we just move pthread_detach call to the worker thread to the > point after pthread_cleanup_pop? I thought that sounded dubious, in that it might lead to an attempt to join a detached thread, but maybe it's safe to assume recv will never return if the mq_notify syscall failed...? Rich