Hi Aurelien, On Tue, 2026-04-07 at 21:44 +0200, Aurelien Jarno wrote: > > At this stage I am not fully convinced: > > - It is not clear to me which software is currently affected by this > bug, and thus it's difficult to judge how important is it to fix this > bug, especially given this is not a regression from bullseye (the bug > is present in that version). Do you have some real examples of > affected software that can show it's important to fix this bug in > bookworm?
That's hard to tell. I'm quite sure that there are Debian package affected by this problem but the "lockup" isn't happening that often, so that those problems likely stay unreported. In our case the 3rd party application is based on the libace, which is also part of Debian. libace is implementing a thread pool based on condition variables. AFAIK the infrastructure around ACE_Task. Threads don't wake up when there is some work to do. I'm quite sure the same pattern is implemented within other Debian packages as well. > > - As said above, there is a risk of breakage, which many users would not > expect now that bookworm is 2+ years old. The bookworm to trixie > upgrade, is different because users expect some breakages for such a > major upgrade and as it is a major glibc upgrade, services were > restarted and systems are often rebooted afterwards. Valid point. See below. Maybe we can do something on the testing side? > > - We have fewer autopkgtest in bookworm than for trixie, which reduces > the chances of catching regressions before they reach a point release. > > In the end we'll need to convince the release team that the bug is > important to fix and there is minimal risk to include it in a point > release. > > In any case I would prefer to avoid including this in the next bookworm > point release (12.14, scheduled for 16 May) as there are already 5 CVE > (+1 pending) to be fixed win this update. I would prefer to avoid the > risk of delaying the glibc update to the next point release in case an > issue is found. Can we do something on the testing side to get better confidence? We're internally stressing the patched glibc package for a couple of days now. The update path was also part of that testing, but for sure we can't cover all possible scenarios. Normally a package would go through the unstable -> testing -> stable chain, which is not possible here because the bug is already fixed in newer releases. Could we use something like "proposed updates" to get additional feedback, so that we could consider this update for the next + 1 point release? Any other ideas? The upstream bug report mentions a couple of other 3rd party software now implementing a workaround for that issue. Broadcasting the condition variable, waking up all threads where n-1 threads go to sleep again immediately. This is a big performance penalty in case a lot of threads are involved. Best regards, Florian
