Bug 274375
| Summary: | page fault while load kernel module virtio | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Zhenlei Huang <zlei> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Open --- | ||
| Severity: | Affects Only Me | CC: | markj |
| Priority: | --- | ||
| Version: | 15.0-CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Zhenlei Huang
2023-10-09 13:55:17 UTC
This looks like a problem with DTrace, there is some logic in sdt.ko's kldunload handler to unregister providers, and something's going wrong there. virtqueue.c defines two rather odd SDT probes, so we're trying to unregister them. (In reply to Mark Johnston from comment #1) > #8 0xffffffff8321b134 in sdt_kld_unload_try () from /boot/kernel/sdt.ko There is no line number of the source code for sdt.ko. I tried addr2line but without luck. So how should I debug this ? And it would be great if we can get line number of source code. Modules are efi-object and relocatable I guess we need extra effort to get the right line number. ** UPDATE ** With 14.0-RC3 I am able to get the line number of sdt.ko. Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 04 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff82e3a134 stack pointer = 0x28:0xfffffe00b0540920 frame pointer = 0x28:0xfffffe00b0540950 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 29038 (kldload) rdi: fffff8002ce880e0 rsi: fffffe00b0540928 rdx: 0000000000000000 rcx: ffffffff82e9d470 r8: 0000000000000004 r9: 00000000000000f3 rax: 0000000000000000 rbx: fffffe00b0540974 rbp: fffffe00b0540950 r10: 0000000000000002 r11: ffffffffffffff90 r12: fffff8000a0d8000 r13: fffffe00b0540974 r14: fffff8000a1e5c40 r15: ffffffff82e9d468 trap number = 12 panic: page fault cpuid = 2 time = 1698979988 KDB: stack backtrace: #0 0xffffffff80b9002d at kdb_backtrace+0x5d #1 0xffffffff80b43132 at vpanic+0x132 #2 0xffffffff80b42ff3 at panic+0x43 #3 0xffffffff8100c85c at trap_fatal+0x40c #4 0xffffffff8100c8af at trap_pfault+0x4f #5 0xffffffff80fe3818 at calltrap+0x8 #6 0xffffffff80b0f73c at linker_file_unload+0xcc #7 0xffffffff810bfa78 at link_elf_load_file+0x198 #8 0xffffffff80b0efb3 at linker_load_module+0x9e3 #9 0xffffffff80b10cba at kern_kldload+0x16a #10 0xffffffff80b10ddc at sys_kldload+0x5c #11 0xffffffff8100d119 at amd64_syscall+0x109 #12 0xffffffff80fe412b at fast_syscall_common+0xf8 Uptime: 1m14s Dumping 452 out of 8100 MB:..4%..11%..22%..32%..43%..54%..61%..71%..82%..92% (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 #1 doadump (textdump=<optimized out>) at /usr/src/sys/kern/kern_shutdown.c:405 #2 0xffffffff80b42cc7 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:526 #3 0xffffffff80b4319f in vpanic (fmt=0xffffffff81136b3b "%s", ap=ap@entry=0xfffffe00b0540770) at /usr/src/sys/kern/kern_shutdown.c:970 #4 0xffffffff80b42ff3 in panic (fmt=<unavailable>) at /usr/src/sys/kern/kern_shutdown.c:894 #5 0xffffffff8100c85c in trap_fatal (frame=0xfffffe00b0540860, eva=0) at /usr/src/sys/amd64/amd64/trap.c:952 #6 0xffffffff8100c8af in trap_pfault (frame=0xfffffe00b0540860, usermode=false, signo=<optimized out>, ucode=<optimized out>) at /usr/src/sys/amd64/amd64/trap.c:760 #7 <signal handler called> #8 0xffffffff82e3a134 in sdt_kld_unload_try (arg=<optimized out>, lf=<optimized out>, error=0xfffffe00b0540974) at /usr/src/sys/cddl/dev/sdt/sdt.c:343 #9 0xffffffff80b0f73c in linker_file_unload ( file=file@entry=0xfffff8003d292180, flags=flags@entry=1) at /usr/src/sys/kern/kern_linker.c:673 #10 0xffffffff810bfa78 in link_elf_load_file (cls=<optimized out>, filename=<optimized out>, result=<optimized out>) at /usr/src/sys/kern/link_elf_obj.c:1241 #11 0xffffffff80b0efb3 in LINKER_LOAD_FILE ( cls=0xffffffff817560a8 <link_elf_class>, result=0xfffffe00b0540c00, filename=<optimized out>) at ./linker_if.h:214 #12 linker_load_file (filename=<optimized out>, result=<optimized out>) at /usr/src/sys/kern/kern_linker.c:459 #13 linker_load_module (kldname=kldname@entry=0xfffff8000a0c3800 "virtio.ko", modname=modname@entry=0x0, parent=parent@entry=0x0, verinfo=verinfo@entry=0x0, lfpp=lfpp@entry=0xfffffe00b0540d90) at /usr/src/sys/kern/kern_linker.c:2203 #14 0xffffffff80b10cba in kern_kldload (td=td@entry=0xfffffe00b1522720, file=file@entry=0xfffff8000a0c3800 "virtio.ko", fileid=fileid@entry=0xfffffe00b0540de4) at /usr/src/sys/kern/kern_linker.c:1162 #15 0xffffffff80b10ddc in sys_kldload (td=0xfffffe00b1522720, uap=<optimized out>) at /usr/src/sys/kern/kern_linker.c:1185 #16 0xffffffff8100d119 in syscallenter (td=0xfffffe00b1522720) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:187 #17 amd64_syscall (td=0xfffffe00b1522720, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1197 #18 <signal handler called> #19 0x00002ab829148b3a in ?? () Backtrace stopped: Cannot access memory at address 0x2ab8285939b8 (kgdb) (In reply to Mark Johnston from comment #1) > This looks like a problem with DTrace, there is some logic in sdt.ko's kldunload > handler to unregister providers, and something's going wrong there. virtqueue.c > defines two rather odd SDT probes, so we're trying to unregister them. That happens when a module file with SDT probes is failed to be loaded by kernel linker. While the kernel try to invoke kld_unload_try event handlers for it and apparently it should not, as the file is in the progress of loading, i.e. it is partially linked. As for > Note: `kldload virtio.ko` can trigger the panic but `kldload virtio` will not. kernel linkers will check module named `virtio` firstly and refuse to load so no bad things happen. But for `virtio.ko` the kernel will load the file and get all modules in it before it knows `virtio` is present. Proposed fix https://reviews.freebsd.org/D44594. |