Run 1 (2026-09-03 09:58 UTC) — race, 6 mounters (root, ext2fs then fuse), kldloop no gap
========================================================================================
NOTE: first two race.sh invocations used stale binaries (tmpfs/ext2fs versions)
and established: (a) tmpfs.ko/null.ko/procfs.ko are built into the kernel
(kldload -> "interface tmpfs.1 already present in the KLD 'kernel'!" /
ENOEXEC), (b) fuse.ko is the only user-cap-relevant loadable fs module.

Run 2 (2026-09-03 10:00 UTC) — race, 6 root mounters (fuse), 2 poc sysctl readers
(vfs.generic.0 — oid wrong, readers idle), kldloop no gap, 300 s budget
========================================================================================
Result: HARD WEDGE at ~60-90 s. All 6 mounters D-state:

  root  1367 D5  ncplk     /root/mountloop /home/poc/mnt fuse
  root  1368 D0  ncplk     /root/mountloop /home/poc/mnt fuse
  root  1369 D2  ncplk     /root/mountloop /home/poc/mnt fuse
  root  1370 D0  ncplk     /root/mountloop /home/poc/mnt fuse
  root  1371 D0  ncplk     /root/mountloop /home/poc/mnt fuse
  root  1372 D0  ncplk     /root/mountloop /home/poc/mnt fuse
  root  1375 R1  -         /root/kldloop            (spinning on failed loads)

fuse.ko pinned loaded (id 4), kldload storm:
  dmesg: interface fuse.1 already present in the KLD 'fuse'! (x2800+)
fuse was loaded mid-race by a mounter's sys_mount autoload path:
  dmesg: fuse_init(mountloop|1367): FUSE ABI 7.28
Guest could not be shut down; vm.sh reset had to hard-kill QEMU.

Run 3 (2026-09-03 10:10 UTC) — CONTROL: 4 mounters (fuse loaded by hand,
no kldunload churn), 90 s
========================================================================================
Result: CLEAN. mloop.0: pid=897 iter=0..600000 ok=0 fail=600001 (~7k
mount(2)/s per mounter), all processes exited cleanly at kill, guest
healthy. => the mount loop by itself is harmless.

Run 4 (2026-09-03 10:09:58 UTC) — RACE: 16 mounters + kldloop (no gap), 600 s
========================================================================================
Result: HARD WEDGE in ~4 min, identical shape (ncplk/syncexit/vnode
D-states, kldloop D, fuse pinned). Wedge survived until forced reset.
Witness ps (excerpt):
  976 D5 ncplk    /root/mountloop ...
  977 D5 syncexit /root/mountloop ...
  983 D5 vnode    /root/mountloop ...
  994 D3 -        /root/kldloop
  sysctlloop (poc) kept running: 84,000,000+ successful vfs.generic
  enumerations (R state) — the list itself remained traversable; the
  wedge owns the mount/linker path.
`ls /` and normal path lookups still worked (wedge scoped to
mount/linker subsystem); wedged threads ignored SIGKILL.

Run 5 (2026-09-03 10:18 UTC) — RACE: 3 mounters + kldloop GAP=10000, 600 s
========================================================================================
Result: HARD WEDGE in ~15 s (fastest yet — fewer threads, same outcome):
  889 D5 vnode    0:06.01 /root/mountloop /home/poc/mnt fuse
  890 D5 -        0:06.48 /root/mountloop /home/poc/mnt fuse
  902 D4 ncplk    0:06.28 /root/mountloop /home/poc/mnt fuse
  905 D4 -        0:07.50 /root/kldloop 10000
  fuse.ko pinned (id 4). mloop.0 had reached iter=200000 before wedging
  (healthy fast loop, then the fatal interleave).

Run 6 (2026-09-03 10:26 UTC) — second concurrent race GAP=50000 on the
still-wedged guest: new mounter 1016 wedged (wchan syncexit) within ~10 s;
old wedged threads (889/890) still present and unkillable.

Panic capture (same session):
  sysctl -w kern.sync_on_panic=1; debug.trace_on_panic=1;
  debug.debugger_on_panic=0; sysctl -w debug.panic=1
  => serial console (dfbsd-qemu/boot.log):
     panic: sysctl_debug_panic
     cpuid = 2
     Trace beginning at frame 0xfffff80118787778
     stack_guard_panic2() at stack_guard_panic2 0xffffffff802cd040
     sysctl_root.isra.5() at sysctl_root.isra.5+0x166
     userland_sysctl() at userland_sysctl+0x111
     sys___sysctl() at sys___sysctl+0x74
     syscall2() at syscall2+0x11e
     boot() called on cpu#2
     syncing disks...            <<< HANGS HERE — crash-dump sync wedges on
                                  the same corrupted VFS state; guest died
                                  mid-sync and never produced a vmcore.
(kill -9 1 does NOT panic a DFly guest — init is signal-protected.)