panic: unmount: dangling vnode   [STOCK kernel, mknod path - PRE-EXISTENCE PROOF]
=========================================================================
Captured from the QEMU serial console (dfbsd-qemu/vm.sh log) immediately
after run_stocknod.sh, Tue Oct 20 13:41 UTC 2026.  Kernel:
DragonFly 6.5-DEVELOPMENT #0: Thu Jul  2 06:02:54 UTC 2026 (STOCK,
no DF-2997 patch applied - verified via uname -v before the run).

Trigger: single truncated NFSv3 MKNOD reply (ok + fhfollow=1 + fh,
nothing else) -> nfs_mknodrpc() takes its STOCK error path which already
uses vput() (sys/vfs/nfs/nfs_vnops.c:1655-1657), leaving one VNON 0-ref
cached vnode -> umount -f.  NO DF-2997 leak site involved.

login: NFS inodes: slab 0xfffff80118660000 1 objects were still allocated
malloc_uninit: 576 bytes of 'NFS inodes' still allocated on cpu 6
panic: unmount: dangling vnode
cpuid = 0
Trace beginning at frame 0xfffff8011856b7b8
dounmount() at dounmount+0x87c 0xffffffff80701bfc
dounmount() at dounmount+0x87c 0xffffffff80701bfc
sys_unmount() at sys_unmount+0x1f2 0xffffffff80701e02
syscall2() at syscall2+0x11e 0xffffffff80bd6a0e
Debugger("panic")

CPU0 stopping CPUs: 0x0000003e
 stopped
Stopped at      Debugger+0x7c:  movb    $0,0xbdaf09(%rip)
db>

Meaning: the "unmount: dangling vnode" panic observed during DF-2997
fix validation is a PRE-EXISTING latent defect reachable on the stock
kernel through an already-vput()ing error path.  Root cause of that
latent defect: vmntvnodescan() skips v_type == VNON vnodes
(sys/kern/vfs_mount.c:931 and :978), so vflush() never processes
never-attributed vnodes and they remain on mnt_nvnodelist when
dounmount() checks it (sys/kern/vfs_syscalls.c:1085-1086).  On the
stock kernel the DF-2997 lock leak masks this by wedging umount -f in
an unkillable D-state sleep even earlier (strictly worse: silent hang
instead of a loud panic).