panic: unmount: dangling vnode   [PATCHED kernel, during fix validation]
=========================================================================
Captured from the QEMU serial console (dfbsd-qemu/vm.sh log) at the end
of run_fixed2.sh, Tue Oct 20 ~13:33 UTC 2026.  Kernel:
DragonFly 6.5-DEVELOPMENT #1: Tue Oct 20 12:55:23 UTC 2026 (nfs_vnops.c
patched with fix.diff: vput() at the nfs_lookup/nfs_mkdir error tails).

At this point in the validation ALL DF-2997 symptoms were already gone
(no wedge, no D-state, vnlru healthy, vnodes reclaiming).  The final
'umount -f /mnt2' of the poisoned mount hit the pre-existing VNON skip
(see panic_stocknod.txt for the stock-kernel proof of pre-existence):

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

CPU4 stopping CPUs: 0x0000002f
 stopped
Stopped at      Debugger+0x7c:  movb    $0,0xbdaed9(%rip)
db>

Only 1-2 VNON vnodes remained dangling (the freshly created 'gzz',
created seconds before umount and not yet reclaimed by vnlru); the
other ~80 had already been reclaimed under maxvnodes pressure on the
patched kernel.  On the stock kernel the same umount does not panic -
it hangs forever in D-state (wchan 'ncplk'/'vnode') because it cannot
lock the wedged vnodes; see run.raw.baseline phase U.