[Bug 295348] ufs: support unmapped bufs causing panic: vm_fault_lookup
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 295348] ufs: support unmapped bufs causing panic: vm_fault_lookup"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 295348] ufs: support unmapped bufs causing panic: vm_fault_lookup"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 295348] ufs: support unmapped bufs causing panic: vm_fault_lookup"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 295348] ufs: support unmapped bufs causing panic: vm_fault_lookup"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 16 May 2026 23:55:03 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295348
Bug ID: 295348
Summary: ufs: support unmapped bufs causing panic:
vm_fault_lookup
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: bugs@FreeBSD.org
Reporter: agh@riseup.net
On 16-CURRENT, the recently committed "ufs: support unmapped bufs for indirect
blocks in bmap"[1], is causing a panic if the host is loaded. This is
reproducible locally when a release.sh build, and poudriere-(testport|bulk) are
run concurrently. release.sh is using null mounted ${SRC}, and ${PORTS}, and
tmpfs ${CHROOTDIR}, poudriere is configured with tmpfs all. The host is an AMD
EPYC 7742 64-Core Processor with 125GiB usable system memory.
> panic: vm_fault_lookup: fault on nofault entry, addr: 0xfffffe00b2840000
> cpuid = 34
> time = 1778975305
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0453921470
> vpanic() at vpanic+0x149/frame 0xfffffe04539215a0
> panic() at panic+0x43/frame 0xfffffe0453921600
> vm_fault() at vm_fault+0x1c0a/frame 0xfffffe0453921780
> vm_fault_trap() at vm_fault_trap+0x65/frame 0xfffffe04539217c0
> trap_pfault() at trap_pfault+0x274/frame 0xfffffe0453921830
> calltrap() at calltrap+0x8/frame 0xfffffe0453921830
> --- trap 0xc, rip = 0xffffffff80a9b100, rsp = 0xfffffe0453921900, rbp = 0xfffffe04539219a0 ---
> ufs_bmap_seekdata() at ufs_bmap_seekdata+0x340/frame 0xfffffe04539219a0
> ufs_ioctl() at ufs_ioctl+0x5f/frame 0xfffffe04539219d0
> VOP_IOCTL_APV() at VOP_IOCTL_APV+0x51/frame 0xfffffe0453921a00
> vn_generic_copy_file_range() at vn_generic_copy_file_range+0x3b4/frame 0xfffffe0453921c00
> vn_copy_file_range() at vn_copy_file_range+0x2e7/frame 0xfffffe0453921ce0
> kern_copy_file_range() at kern_copy_file_range+0x47c/frame 0xfffffe0453921dc0
> sys_copy_file_range() at sys_copy_file_range+0x78/frame 0xfffffe0453921e10
> amd64_syscall() at amd64_syscall+0x164/frame 0xfffffe0453921f30
> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0453921f30
> --- syscall (569, FreeBSD ELF64, copy_file_range), rip = 0x824a11aba, rsp = 0x820893a38, rbp = 0x820893d70 ---
> KDB: enter: panic
> [ thread pid 3235 tid 101303 ]
> Stopped at kdb_enter+0x33: movq $0,0xba0cd2(%rip)
> db>
1:
https://codeberg.org/FreeBSD/freebsd-src/commit/bab04ddf1fd4b7a77d1cfae4a67ededf1f35ee0d
--
You are receiving this mail because:
You are the assignee for the bug.