* Aurelien Jarno: > Hi, > > On 2026-10-21 13:03, Nick Desaulniers wrote: >> On 2026-04-08 11:11, Florian Bezdeka wrote: >> > 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. >> >> Hi, I think we're also hitting this issue on Android's host build >> machines running bookworm; it seems that LLVM's multithreaded linker, >> lld, can miss wakeup signals causing the linker to deadlock. >> >> See also: https://github.com/llvm/llvm-project/pull/231314 >> >> Did this ever end up getting resolved? > > At this stage no. > > The patchset is not trivial, and while it definitely fixes the issue, we > know it breaks software using process-shared condition variables in > files on disk, which at minimum needs to be restarted. > > It is difficult to evaluate what could be the impact of bookworm as a > whole and on usual third party software used on it. At least compared to > RPM based distributions we know that the upgrade part is not an issue > (db5.3 in bookworm is not patched for this issue). And the fact it is > not a regression from bullseye, makes it more problematic to possibly > break other things. > > Now, if the debian-lts team has more ressources to evaluate that, or if > they want to take the risk, it's pretty fine.
I did the backport upstream to glibc 2.36 today and ran the testsuite on x86-64 and ppc64le, with no unexplained failures. (There were some expected failures due to kernel backports on the hosts that were used for testing.) [PATCH 2.36 COMMITTED 01/10] pthreads NPTL: lost wakeup fix 2 <https://inbox.sourceware.org/libc-stable/14c5014e1c1aedbf6742f46b26ade61c8858d567.1793561338.git.fwei...@redhat.com/> The backport is identical to the 2.38 backport that was already available upstream, except for a spurious conflict in code that was being deleted (a typo had been fixed during 2.38 development). It should be pretty safe. The same fixes have been backported to even earlier glibc release downstream (2.28 and 2.34). The main known risk is breaking the frozen condition variables in certain Berkeley DB environments (relevant to db5.3, for example). This was true for later Debian releases as well, and did not block the backport there. I can submit an MR against glibc in Salsa if that would help? There is just one other fix on the upstream branch, and installed header fix for improved compatibility with newer kernels.
