Bug 253617 - ffs_sbget: panic: Unregistered use of FPU in kernel
Summary: ffs_sbget: panic: Unregistered use of FPU in kernel
Status: Closed Not A Bug
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-fs (Nobody)
Keywords: panic
Depends on:
Reported: 2021-02-18 11:01 UTC by Alex Richardson
Modified: 2021-02-19 17:10 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Alex Richardson freebsd_committer 2021-02-18 11:01:09 UTC
I got this panic running the testsuite QEMU (with KVM acceleration on a Linux host)

sys/fs/tmpfs/sizes_test:big  ->  passed  [3.585s]
sys/fs/tmpfs/trail_slash_test:main  ->  passed  [0.971s]
sys/fs/tmpfs/truncate_test:basic  ->  passed  [1.071s]
sys/fs/tmpfs/times_test:rename  ->  passed  [2.684s]
panic: Unregistered use of FPU in kernel
cpuid = 4
time = 1613595474
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0051a70820
vpanic() at vpanic+0x188/frame 0xfffffe0051a70870
panic() at panic+0x43/frame 0xfffffe0051a708d0
trap() at trap+0x273/frame 0xfffffe0051a709e0
calltrap() at calltrap+0x8/frame 0xfffffe0051a709e0
--- trap 0x16, rip = 0xffffffff81059ffe, rsp = 0xfffffe0051a70ab0, rbp = 0xfffffe0051a70ac0 ---
sse42_crc32c() at sse42_crc32c+0x7e/frame 0xfffffe0051a70ac0
readsuper() at readsuper+0x120/frame 0xfffffe0051a70b00
ffs_sbget() at ffs_sbget+0x91/frame 0xfffffe0051a70b70
g_label_ufs_taste_common() at g_label_ufs_taste_common+0x79/frame 0xfffffe0051a70bb0
g_label_taste() at g_label_taste+0x1a6/frame 0xfffffe0051a70c90
g_new_provider_event() at g_new_provider_event+0x9a/frame 0xfffffe0051a70cb0
g_run_events() at g_run_events+0x176/frame 0xfffffe0051a70cf0
fork_exit() at fork_exit+0x80/frame 0xfffffe0051a70d30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0051a70d30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 13 tid 100074 ]
Stopped at      kdb_enter+0x37: movq    $0,0x1292e4e(%rip)
Comment 1 Konstantin Belousov freebsd_committer 2021-02-19 12:45:02 UTC
If you turn off acceleration, or use different hypervisor or bare metal, do you
see the same problem?

I believe this is a hypervisor bug, OS cannot/should not do anything there.
Comment 2 Alex Richardson freebsd_committer 2021-02-19 12:48:21 UTC
This seems to happen with TCG as well, so it's not KVM. Possibly a generic QEMU bug then?
Comment 3 Alex Richardson freebsd_committer 2021-02-19 12:50:20 UTC
Note: this is QEMU running with as `qemu-system-x86_64 -M accel=tcg -cpu Nehalem -smp 8 -m 2048 -nographic -drive if=none,file=/local/scratch/alr48/cheri/output/freebsd-amd64.img,id=drv,format=raw -device virtio-blk-pci,drive=drv`, so possibly related to the -smp option. I have not seen it without QEMU's smp flag.
Comment 4 Konstantin Belousov freebsd_committer 2021-02-19 12:55:39 UTC
Note that CRC32 instruction is qualified on SSE4.2, but it does not use any
of FPU registers.  It operates on GPR so it does not require saving user context
before executing in kernel.

It should not even cause #NM (Device Not Available) exception at all, according
to SDM.  Adding fpu_kern_enter() around it would hugely hit non-buggy environments
like bare metal or non-buggy hypervisors.

Try to report it to QEMU devs.
Comment 5 Alex Richardson freebsd_committer 2021-02-19 16:11:00 UTC
I just had a look at the QEMU TCG code for crc32 and it does not seem like it can raise anything other than #UD.
Unless of course there is a bug in the decoding logic and it is treating

<+126>:	crc32q %rsi,%rbx as a different instruction. GDB says the raw bytes are as follows:
0xffffffff8105a4de <+126>:	f2 48 0f 38 f1 de	crc32q %rsi,%rbx
0xffffffff8105a4e4 <+132>:	f2 48 0f 38 f1 ca	crc32q %rdx,%rcx.
So this does sound like it must be a QEMU bug.
Comment 6 Alex Richardson freebsd_committer 2021-02-19 17:10:13 UTC
Reported upstream as https://bugs.launchpad.net/qemu/+bug/1916269