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 19458 invoked from network); 16 Dec 2021 18:16:23 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 16 Dec 2021 18:16:23 -0000 Received: (qmail 31940 invoked by uid 550); 16 Dec 2021 18:16:20 -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 31899 invoked from network); 16 Dec 2021 18:16:19 -0000 Date: Thu, 16 Dec 2021 13:16:07 -0500 From: Rich Felker To: zuotina Cc: musl@lists.openwall.com Message-ID: <20211216181600.GN7074@brightrain.aerifal.cx> References: <57cc3430.7783.17dc3d9431a.Coremail.zuotingyang@126.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57cc3430.7783.17dc3d9431a.Coremail.zuotingyang@126.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [pthread] pthread_barrier_wait invalid case On Thu, Dec 16, 2021 at 11:25:35PM +0800, zuotina wrote: > Hi everrone > > > I encountered a panic problem when using timer_create recently. > Although the probability is small, it still happened. > Finaly I found there is a problem in the code of phtread_barrier_wait, > and review code found that there may be problems in the following place, > 81 a_store(&b->_b_lock, 0); > 82 if (b->_b_waiters) __wake(&b->_b_lock, 1, 1); > If scheduling occurs between lines 81 and 82, it will be not good. > So I did an experiment and modified the source code of pthread_barrier_wait to verify my guess > ```c > 81 a_store(&b->_b_lock, 0); > /* If it is scheduled out here, when another thread executes pthread_barrier_wait again, > it can go through the entire function happily, that is, it will not be blocked */ > syscall(yiled); // new add for test > // When the dispatch comes back, this b has been released > 82 if (b->_b_waiters) __wake(&b->_b_lock, 1, 1); > ``` The intent here is that it's not possible that b has been released, because all waiters have to synchronize on b->_b_inst. It's possible there's a bug here. I'll look. What arch are you running on? > Here is an example of timer_create (src/time/timer_create.c) > There are two threads A and B call pthread_barrier_wait. > The call is as follows > A thread: (timer_create // parent thread) > { > ..... > // new add for test---begin > while(b->_b_inst == NULL) { > syscall(yield); > } > // new add for test---end > pthread_barrier_wait(); > } > B thread: (start // child thread) > { > ..... > // Ensure that this function is advanced to the if (!inst) {} branch of barrier_wait > pthread_barrier_wait(); > } > > > In short, the reason for panic is that pthread_barrier_wait is not blocked as expected; > I hope you help to confirm whether there is a problem with the implementation > of pthread_barrier_wait or am I wrong? > > > Looking forward to your reply. Thank you. Thanks for the report. Rich