panic: BADFREE2                                    [run 1 - 2026-09-27 05:47:12, ~35 s into lockdrive_recursion v3 (90 s, 8 racers)]
cpuid = 3
Trace (interleaved with concurrent vinum console spam "vinum: drive d0 is up" /
       "vinum: plex p0 does not have at least 3 subdisks"):
_kfree() at _kfree+0x593
mapped_ioctl() at mapped_ioctl+0x492
syscall2() at syscall2+0x11e
Debugger("panic")
CPU3 stopping CPUs: 0x0000003b
 stopped
Stopped at      Debugger+0x7c:  movb    $0,0xbdaf09(%rip)
db>

=== run 2 - 2026-09-27 05:52:56 (~3-6 s into lockdrive_recursion v3 (60 s, 6 racers),
=== fresh boot, fresh vinum config, dmesg cleared; full unshredded trace:

panic: BADFREE2
cpuid = 2
Trace beginning at frame 0xfffff80117c2b7d8
_kfree() at _kfree+0x593 0xffffffff80658413
_kfree() at _kfree+0x593 0xffffffff80658413
mapped_ioctl() at mapped_ioctl+0x492 0xffffffff806a81b2
syscall2() at syscall2+0x11e 0xffffffff80bd6a0e
Debugger("panic")

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

Context both runs:
- guest DragonFly 6.5-DEVELOPMENT #0 Thu Jul  2 06:02:54 UTC 2026 X86_64_GENERIC, 6 vCPU
- vinum RAID-5 volume rv on vn-backed drives x0/x1/x2 (up), drive d0 on /dev/vn3s1a
- PoC: one process spawns the vinum daemon inside itself (VINUM_DAEMON ioctl,
  vinumioctl.c:296 -> vinum_daemon() in the caller's process context), then
  6-8 "downer" threads issue VINUM_SETSTATE(drive,down,force) + VINUM_REMOVE
  on the drive slots while "cycler" threads re-create + force-up the drive
  (fresh on-disk label + VINUM_CREATE + VINUM_SETSTATE up) in a 20 ms loop.
- BADFREE2 = DragonFly kfree() integrity check: the freed pointer is not a
  live allocation (double free / stale free). The freed memory is the vinum
  drive-teardown path's allocations (drive->freelist via free_drive/
  set_drive_parms, or the remove_drive label buffer) -- the exact section
  that lockdrive()/unlockdrive() (vinumlock.c) nominally serialize, and the
  section whose pid-based "recursion" early-return admits a second
  same-process thread while the first sleeps in vn_close().
- 2/2 full runs of the race panicked; both wedged the guest in DDB (db>)
  requiring vm reset.