DF-3169 PANIC #1 (harness-artifact WARN, interleaving proof)
==============================================================

Guest: DragonFly 6.5-DEVELOPMENT #0 X86_64_GENERIC (INVARIANTS)
Harness: df3169_race.ko v1 (kthread W in autofs_trigger vs dounmount MNT_FORCE)

Serial console (dfbsd-qemu/vm.sh log), decisive lines:

  DF3169: harness loaded, scanning for autofs mount...
  DF3169: mp=0xfffff8008fa6fc00 amp=0xfffff8008d6fb200 root anp=0xfffff8008f890600 last_request_id=0
  DF3169: calling dounmount(MNT_FORCE) (ticks=153961)
  Fatal trap 12: page fault while in kernel mode
  cpuid = 1; lapic id = 1
  fault virtual address	= 0x5c
  fault code		= supervisor read data, page not present
  instruction pointer	= 0x8:0xffffffff82601b2c
  current process	= Idle
  kernel: type 12 trap, code=0
  Stopped at      autofs_trigger+0x28c:   movl    0x5c(%rax),%r8d
  db>

Interpretation (verified against source):
  * The panic is inside autofs_trigger() while dounmount(MNT_FORCE) is in
    progress (between "calling dounmount" and "dounmount returned").
  * Fault va 0x5c (small offset from NULL) with current process "Idle"
    identifies the AUTOFS_WARN in autofs_trigger_one()
    (sys/vfs/autofs/autofs.c:386-388) dereferencing curproc->p_pid /
    curproc->p_comm.  curproc is NULL because W is a raw kernel thread.
    Real triggers always run in process context (stat/getdents), so the
    NULL itself is a HARNESS artifact, not the product bug.
  * What it DOES prove: W was mid-autofs_trigger when the forced unmount
    ran; the request-drain loop ENXIO-completed W's request
    (autofs_vfsops.c:223-226) exactly as predicted, i.e. the retry-loop
    interleaving of DF-3169 fired within the first ~2 seconds.

The follow-up run (run.log / VERDICT.md) disables vfs.autofs.debug so the
WARN body is skipped (its arguments are only evaluated inside the
`if (autofs_debug > 0)` guard) and lets W proceed past the WARN into the
post-free retry attempts on the freed anp/amp.