Re: [GIT PULL] s390 fixes for 6.17-rc3

[Heiko Carstens <hca@linux.ibm.com>]

On Thu, Oct 02, 2025 at 12:44:41AM +0200, Thomas Weißschuh wrote:
> Hi Alexander, Vasily and Heiko,
> 
> On 2025-08-22 14:36:08+0200, Alexander Gordeev wrote:
> > please pull s390 fixes for 6.17-rc3.
> 
> (...)
> 
> >       s390/configs: Set HZ=1000
> 
> With this commit the nolibc testsuite for 32bit on QEMU 10.1.0 starts to
> reliably crash. 64bit is fine. Actually I encountered the same problem
> before this change, but it happened much less frequently.
> Output below for a testrun that never got to print anything to stdout,
> but the crashes can also happen later or sometimes not at all.
> 
> [    2.118473] Run /init as init process
> [    2.142148] User process fault: interruption code 0006 ilc:0
> [    2.142626] CPU: 0 UID: 0 PID: 1 Comm: init Not tainted 6.17.0-rc2-00002-gfcc43a7e294f #24 NONE
> [    2.142739] Hardware name: QEMU 8561 QEMU (KVM/Linux)
> [    2.142822] User PSW : 0705200080000000 00000000804087b2
> [    2.142911]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:2 PM:0 RI:0 EA:1
> [    2.142979] User GPRS: 0000000000000000 000000000040c060 ffffffffffffffff 0000000000000002
> [    2.143022]            0000000000000800 00000000000007ff 0000000000000000 0000000000000000
> [    2.143061]            0000000000000000 000003ff00000001 000000000040c000 000000007ff720ac
> [    2.143106]            000000007ff720a4 0000000000409540 00000000804087b2 000000007ff71ec0
> [    2.143406] User Code: Bad PSW.
> [    2.143454] Last Breaking-Event-Address:
> [    2.143483]  [<0000000000000001>]
> [    2.144705] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
> [    2.144875] CPU: 0 UID: 0 PID: 1 Comm: init Not tainted 6.17.0-rc2-00002-gfcc43a7e294f #24 NONE
> [    2.144922] Hardware name: QEMU 8561 QEMU (KVM/Linux)
> [    2.144989] Call Trace:
> [    2.145292]  [<000003fffe657cf4>] vpanic+0x1dc/0x2f0
> [    2.145535]  [<000003fffe657e4e>] panic+0x46/0x48
> [    2.145586]  [<000003fffe65e4e2>] do_exit+0x3da/0x520
> [    2.145634]  [<000003fffe65e820>] do_group_exit+0x40/0xb8
> [    2.145683]  [<000003fffe66fc98>] copy_siginfo_to_user+0x0/0x60
> [    2.145735]  [<000003fffe60614e>] arch_do_signal_or_restart+0x66/0x2b0
> [    2.145787]  [<000003ffff42e2bc>] irqentry_exit_to_user_mode+0x174/0x1f8
> [    2.145902]  [<000003ffff439d5c>] pgm_check_handler+0x114/0x160
> 
> You can run the testuite for yourself:
> (run-tests.sh will download a cross toolchain)
> 
> $ cd tools/testing/selftests/nolibc
> $ ./run-tests.sh -p s390
> (Expected output, lower numbers mean failures)
> s390:          228 test(s): 227 passed,   1 skipped,   0 failed => status: warning
> 
> The full test output will be in run.out.
> 
> This doesn't feel like an issue in nolibc to me.
> Any ideas?

Hm, this looks like a qemu bug to me.

Ilya, could you have a look at this please?

The above report is a specification exception with an instruction length
code of zero, while the PSW points to a 31 bit user space address. As far
as I understand the architecture this is only possible for an early PSW
specification exception (aka invalid PSW); however the PSW looks good to
me.

So something seems to be odd here.