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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2786 invoked from network); 11 Feb 2023 18:09:08 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 11 Feb 2023 18:09:08 -0000 Received: (qmail 8156 invoked by uid 550); 11 Feb 2023 18:09:05 -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 8121 invoked from network); 11 Feb 2023 18:09:05 -0000 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru B37E940737BB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru; s=default; t=1676138933; bh=TjwHaerxC9qTswMeuHUiJkfiIo4iUUIUjwOfr+bGGNc=; h=Date:From:To:Subject:In-Reply-To:References:From; b=UdKgbBdBSUCv6/p8mmRrSj5WBmSP0n5LF5VsTxBmwitZSSIqZupKKTHgTOfb5oIoQ BMSVl679FG3BALAGeZixjYu3CEhqVd5PZ6/tnu9b85Hw/etzcx3Qq6vF44+xw7ZgXk Rx4NUU4Q9mmcH7pxCxeDC0stc/YprlygzcXqBCpA= MIME-Version: 1.0 Date: Sat, 11 Feb 2023 21:08:53 +0300 From: Alexey Izbyshev To: musl@lists.openwall.com In-Reply-To: <20230211175948.GK4163@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> User-Agent: Roundcube Webmail/1.4.4 Message-ID: X-Sender: izbyshev@ispras.ru Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [musl] [PATCH] mq_notify: fix close/recv race on failure path 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? Alexey