# DF-3962 verdict — certain source-level race, hardware-gated

## Reproduced?
No: guest has no HighPoint/mvfrey device (env.txt). Source analysis is
conclusive.

## The race, path:line
1. hptiop.c:2647–2650 — per-CCB 20 s callout armed on every mvfrey SCSI post;
   arg is `hba` (not the ccb), so the timeout never completes *its* CCB.
2. hptiop.c:2244–2250 — `hptiop_reset_adapter` calls
   `hptiop_send_sync_msg(hba, IOPMU_INBOUND_MSG0_RESET, 60000)` with NO
   adapter lock. XPT_RESET_BUS calls it under the lock (2350–2353) — the
   lock is `LK_CANRECURSE` (1899) so fix.diff locking is safe for both paths.
3. hptiop.c:899–906 — `hptiop_send_sync_msg` polls `hba->ops->iop_intr(hba)`
   directly; for mvfrey that is `hptiop_intr_mvfrey` (760–802) which drains
   the outlist with the shared, non-atomic `hba->u.mvfrey.outlist_rptr`
   (782–795) and completes tags via `hptiop_request_callback_mvfrey`.
4. hptiop.c:2163–2169 — `hptiop_pci_intr` holds the lock around the same
   `iop_intr`; lock discipline is *inconsistent* between the two callers, so
   there is NO mutual exclusion between them.
5. Both CPUs can read the same outlist entry → same `_tag` completed twice →
   `hptiop_free_srb` twice (srb freelist aliasing: two future CCBs share one
   srb and its DMA request buffer) and `xpt_done(ccb)` twice (CAM UAF).
6. Bonus: 60000 ms of `DELAY(1000)` polling inside a callout (softclock
   context) starves the CPU; and reset wipes firmware queues while in-flight
   SRBs are never reaped (ccb leak / CAM wedge).

Sibling comparison: sys/dev/raid/hptmv/entry.c:2626-2633 and
sys/dev/raid/hpt27xx/hpt27xx_osm_bsd.c:528-532 both take their driver lock
inside the timeout handler before resetting.

## Fix
fix.diff takes `hptiop_lock_adapter` around the reset in
`hptiop_reset_adapter` (safe for the recursive XPT_RESET_BUS path).
A fuller upstream fix should also abort/complete the timed-out CCB and avoid
the 60 s busy-wait in callout context.

## 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.