Hi Michael, Thanks for sharing the detailed analysis on this issue. Let me check this with the team here and from s390x core team, will keep you posted.
Thanks, -Dipak Zope From: Dipak Zope1 <[email protected]> Date: Monday, 6 February 2023 at 7:02 PM To: Michael Tokarev <[email protected]>, [email protected] <[email protected]> Subject: Re: [EXTERNAL] suspecting 5.10.0-21 kernel breaking something with futexes on s390x Hi Michael, Thanks for sharing the detailed analysis on this issue. Let me check this with the team here and from s390x core team, will keep you posted. Thanks, -Dipak Zope From: Michael Tokarev <[email protected]> Date: Monday, 6 February 2023 at 6:59 PM To: [email protected] <[email protected]> Subject: [EXTERNAL] suspecting 5.10.0-21 kernel breaking something with futexes on s390x #1030545 reported against qemu. The issue is rather fundamental for qemu, it is one of the very basic operations. I can reproduce the same issue on older versions as well, even installed bullseye chroot on zelenka.d.o and it fails/hangs the same way there. A common pattern is the usage of 5.10.0-21 kernel. For example, last successful builds of libguestfs (which suffered from this issue) were done on hosts running previous kernel version, and there's no single successful build on 5.10.0-21. Zelenka is also running 5.10.0-21, - I asked to reboot it into -20 to see if it changes something. We tried to run it on other s390x machines, - the bug does not show itself there. But these run other kernels. I looked at the changes between -20 and -21, 5.10.150 -> 5.10.162, and I do see at least one s390x-specific change to futexes (and it is the futex which behave in a weird way now), plus changes in signal/wakeup handling. Also, there are other changes past .162 which includes quite some changes to s390x atomix/cmpxchg stuff. So it *might* be related. At any rate, with the data points I have so far, everything points to the kernel. If anyone know what's going on there, please do share your knowledge :) Thanks, /mjt
