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

> Date: Sun, 02 Aug 2026 01:43:31 +0200
> From: Bruno Haible <[email protected]>
>=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