DF-2676 panic capture (verbatim from QEMU serial console, vm.sh log, guest
DragonFly 6.5-DEVELOPMENT #0 X86_64_GENERIC, 2026-08-30 13:30 UTC, directly
after `kldload /root/df2676_mod/df2676.ko` as root):

login: DF-2676: loaded, page 0xfffff80049701200 busied in obj 0xfffff801173cd100
DF-2676: grabber: calling vm_page_grab(obj, 0, VM_ALLOC_NORMAL) - NO VM_ALLOC_RETRY - on busy page
DF-2676: holder: waking busy page 0xfffff80049701200
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic id = 1
fault virtual address	= 0x76
fault code		= supervisor read data, page not present
instruction pointer	= 0x8:0xffffffff802aad22
stack pointer	        = 0x10:0xfffff801182cba50
frame pointer	        = 0x10:0xfffff801182cbaa0
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, long 0, def32 0, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= Idle
current thread          = pri 12 
kernel: type 12 trap, code=0
CPU1 stopping CPUs: 0x0000003d
 stopped
Stopped at      vm_page_grab.cold.30:   movzbl  0x76,%eax
db> 

Analysis:
- fault VA 0x76 == offsetof(struct vm_page, valid) on x86_64 (pageq 0x00,
  rb_entry 0x10, spin 0x20, md_page 0x28..0x75, valid 0x76).
- Faulting instruction `movzbl 0x76,%eax` inside vm_page_grab is the load of
  m->valid at sys/vm/vm_page.c:3882 with m == NULL, exactly the
  `m = NULL; break;` error path from vm_page.c:3841-3843.
- The "holder: waking busy page" line printed immediately before the trap
  proves the sequence: grab -> lookup_busy_try error (page PBUSY_LOCKED by
  us) -> vm_page_sleep_busy slept once -> holder's vm_page_wakeup() released
  the sleep -> grab set m = NULL and dereferenced it.

(Prior KLD iteration, for the record: doing vm_object_hold() directly in
MOD_LOAD (syscall context) instead panics with "syscall: 1 extra tokens held
after trap!" - a PoC artifact, not the bug under test; fixed by moving all
object work into a kernel thread.)