Re: Re: kern/60220 (kernel panic after modifying floating-point status register)

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/60220; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Bruno Haible <bruno%clisp.org@localhost>
Cc: kern-bug-people%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
	gnats-admin%netbsd.org@localhost, gnats-bugs%netbsd.org@localhost
Subject: Re: 
	Re: kern/60220 (kernel panic after modifying floating-point status register)
Date: Sun, 2 Aug 2026 02:03:44 +0000

 > Date: Sun, 02 Aug 2026 01:43:31 +0200
 > From: Bruno Haible <bruno%clisp.org@localhost>
 >=20
 > This kernel panic, triggered by a program run by an unprivileged user,
 > is still reproducible in NetBSD 11.0 (release) / x86_64.
 
 Sorry about that, lost track of this one.
 
 Still haven't reproduced it, but I don't have vbox handy to test.
 Were you able to reproduce it in any environment other than vbox?
 
 The stack trace is weird -- it doesn't have anything past the
 hardclock frame:
 
 panic: cpu0: softints stuck for 16 seconds
 cpu0: Begin traceback...
 vpanic() at netbsd:vpanic+0x171
 panic() at netbsd:panic+0x3c
 heartbeat() at netbsd:heartbeat+0x1f2
 hardclock() at netbsd:hardclock+0x9c
 cpu0: End traceback...
 
 But the first line of ps-part1.png shows that the process running your
 test program is still on the CPU:
 
 PID     LID S CPU     FLAGS       STRUCT LWP *                NAME WAIT
 1352 > 1352 7   0   1000000   ffff85008503dc00    test-fenv-except
 
 The FLAGS column, struct lwp::l_flag, has this bit set:
 
 #define LW_PENDSIG      0x01000000 /* Pending signal for us */
 
 So I'm guessing the system is trying to deliver SIGFPE, but it's
 hitting some kind of trap loop.
 
 Can you try running the NetBSD ATF tests in this environment to see if
 they also reproduce the crash?
 
 cd /usr/tests/lib/libc && atf-run | atf-report
 cd /usr/tests/lib/libm && atf-run | atf-report
 cd /usr/tests/kernel && atf-run | atf-report
 
 There are a good number of tests among those three directories that
 test mxcsr access and trapping floating-point exceptions SIGFPE.  And
 although some of them (notably the ptrace tests) are sometimes flaky,
 they certainly don't panic the kernel on physical amd64 or a qemu
 amd64 guest:
 
 https://www.gson.org/netbsd/bugs/build/amd64-baremetal/2026/2026.08.01.11.5=
 7.24/test.html#failed-tcs-summary
 https://releng.netbsd.org/b5reports/amd64/2026/2026.08.01.20.48.03/test.html