=== DF-2450 panic signature (from serial console, pre-reset) ===
=== Trigger: linear reload with regular file /tmp/testfile as backing path ===
=== Root cause: dm_pdev_insert line 168 dev_dioctl(v_rdev=NULL, DIOCGPART) ===

Fatal user address access from kernel mode from test2 at ffffffff8062cd5c

Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic id = 1
fault virtual address	= 0xa8
fault code		= supervisor read data, page not present
instruction pointer	= 0x8:0xffffffff8062cd5c
stack pointer	        = 0x10:0xfffff80118347478
frame pointer	        = 0x10:0xfffff801183474d8
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		= 922
current thread          = pri 6
kernel: type 12 trap, code=0

CPU1 stopping CPUs: 0x0000003d
 stopped
Stopped at      dev_dioctl+0xc: movq    0xa8(%rdi),%rax
db>

=== Notes ===
- v_rdev is NULL for regular file vnodes (VBLK not set)
- dm_pdev_insert:168 calls dev_dioctl(dmp->pdev_vnode->v_rdev, ...) unconditionally
- %rdi = NULL (v_rdev), instruction reads 0xa8(%rdi) = 0xa8 -> page fault
- For /dev/null (char device), v_rdev IS set, DIOCGPART fails cleanly (ENODEV=19)
  and the "dmp_pdev_insert DIOCGPART failed 19" message is printed (no panic)
- The finding's description ("path does NOT resolve") was imprecise; the actual
  trigger is a path that resolves to a NON-block-device vnode (regular file).
  The underlying bug is real and IS in dm_pdev.c:168.