From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1BDA43856DC8; Thu, 6 Oct 2022 21:58:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1BDA43856DC8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1665093507; bh=pIDZ0Cgy7gmpevOVINBM3lIo2RmclFyOhTSx2WidT/0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EEJHMUhOuQKd2qlunvPb+utKfdkaPlA1se676hHboEirhbRzibqVhOYlL+lzjAfQO AZUK30Dduie2Ph/AdS3Gqz4ihmCUL0lVgApWZAyzw6bsv6Y8dzF6Wcl3IKiB2ou3MH 4L7Mnn2qByR55PhtYi3cBH6O0uDKgD52sCKeGtfc= From: "malteskarupke at fastmail dot fm" To: glibc-bugs@sourceware.org Subject: [Bug nptl/25847] pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing Date: Thu, 06 Oct 2022 21:58:25 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: 2.27 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: malteskarupke at fastmail dot fm X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: carlos at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D25847 --- Comment #50 from Malte Skarupke --- I sent a new version of my patch series: https://sourceware.org/pipermail/libc-alpha/2022-October/142562.html It fixes the issue where the first patch applied on its own didn't work. (it had a bug that was fixed by the third patch in the series) I also rebased t= he patch to work on top of release/2.36/master. I'm pretty confident that these fix the issue, but they do still need revie= w. I am also still thinking of doing the following two things: 1. Properly review Frank Barrus' patch, because from the little I looked at= , I like it and it might be a better solution than the patch I submitted here. 2. Maybe submit a patch that just allows more spurious wakeups. The original problem was that if a waiter takes too long to wake, and the group switched twice, it could steal a signal from a later group and a waiter from a later group would go back to sleep. And then the code that was supposed to handle that caused this bug. But my current thinking is "what if the thread whose signal got stolen just doesn't go back to sleep?" Meaning you'd be fine with slightly more spurious wakeups in edge cases. I think it would simplify a l= ot. Still don't have a lot of time to work on this though. So I first just want= ed to get my patch back into a good condition. I think the first patch in the series is a low-risk fix, after it has been reviewed and tested a bit more.= It doesn't change much and I actually did the work of verifying it in TLA+. --=20 You are receiving this mail because: You are on the CC list for the bug.=