# DF-3922 VERDICT

**status: not_reproduced (hardware-gated race)** | **impact observed: none (potential: permanent kernel/storage wedge)** | **source certainty: likely**

## Mechanics verified at source level
1. `callout_stop()` on DragonFly is synchronous: kern_timeout.c:1091-1094
   passes sync=1; _callout_cancel_or_stop (kern_timeout.c:859-930) at
   :910-921 sleeps in `ssleep(..., "costp", 0)` — no timeout — while the
   callback is CALLOUT_INPROG.
2. `hpt_timeout` (entry.c:2625-2632) executes `lock_driver()` as its first
   action and only then resets the bus.
3. `fOsCommandDone` (entry.c:2910) calls `callout_stop(ccb->ccb_h.timeout_ch)`
   while running under `driver_lock` (every CheckPendingCall/DPC execution
   context in this driver holds it: hpt_intr 2123-2132, hpt_action 2273-2286,
   worker 2408-2428).
4. => if the callout fires concurrently with a completion holding the lock,
   CPU0 sleeps in "costp" holding driver_lock, CPU1 sleeps in lockmgr waiting
   for driver_lock. Neither has a timeout. controller + DPC worker + all CAM
   entries wedge; because the SIM uses &sim_mplock (entry.c:2047), the giant
   CAM MP lock serializes other legacy SIMs against blocked entrants.

## Why "likely" and not "certain"
The window requires the 20 s callout to begin executing in the exact
microseconds a completion under driver_lock reaches callout_stop. The
mechanism is certain (verified code), the manifestation is a rare race —
hence confidence "likely". Hardware-gated: cannot be raced on the audit
guest (no RR1820).

## Note
hptmv also *reuses* the CCB's CAM-owned callout (ccb_h.timeout_ch) for its
private timeout — CAM allocates/frees this callout (cam_xpt.c:4934-4945);
the stop/start dance here is the only synchronization, which is what makes
the synchronous-stop semantics load-bearing for correctness.

## Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest `make -j6 nativekernel KERNCONF=X86_64_GENERIC` completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.