DF-4203 VERDICT — unlocked re-entrant probe in XPT_SCSI_IO (ahci_cam.c)

Bottom line (2026-10-15 re-verification with live AHCI hardware)

Race consequence REPRODUCED twice on live hardware (trigger state injected); natural arming remains hardware-gated (SATA PM). With a real AHCI controller + disk on the guest, forcing at->at_probe = ATA_PROBE_NEED_IDENT (the state whose ONLY production producer is the PM hard-reset completion at ahci_pm.c:876) while normal I/O, device resets and pass CCBs run concurrently, the unlocked re-probe at ahci_cam.c:989-990 panics the kernel within seconds in exactly the double-completion mode the finding predicts. The identical load WITHOUT arming (control) survives clean. The locking asymmetry itself (ahci_cam_probe called under ap_sim_lock only) is unchanged in source.

1. What is new vs the first verification round

The first round (this directory, earlier VERDICT) correctly identified the two-lock design, the single unlocked caller, and the PM-only arming problem, and could not test: the guest had no AHCI controller and QEMU could not boot with one. This round got live AHCI hardware by attaching -device ahci + ide-hd/ide-cd at QEMU launch (up_ahci.sh; boot order pinned via bootindex — the old firmware hang was an artifact of the earlier invocation). ahci0.0 DISK (tags=32/32) = da0/pass0, ahci0.1 ATAPI = cd0/pass1.

2. Live runs (race.sh, 2026-10-15)

Armed run = 4 concurrent dd readers on da0 + camcontrol reset da0 loop (locked state-machine probes) + continuous pass XPT_SCSI_IOs + KLD arming at_probe = NEED_IDENT continuously for 25-45s (df2420_rig.c arm command — reaches the real port via devclass_find("ahci")).

Run 1 (45s arm) — panic in <45s (panic-race.txt):

• dmesg shows repeated concurrent probes (ahci0.0: Found DISK ... many times) from the NEED_IDENT branch while dd IO completes.
• panic: assertion "xa->state != ATA_S_ONCHIP && xa->state != ATA_S_PUT" failed in ahci_ata_cmd_done at ahci.c:3776 (the panic line is character-interleaved on the serial console with a concurrent probe's Found DISK kprintf from another CPU — itself proof of unsynchronized concurrent execution).
• Backtrace: ahci_ata_cmd_done ← ahci_ata_cmd_done ← ahci_port_intr ← ahci_port_thread_core ← ahci_port_thread — the port thread completed a ccb whose xa had already been PUT (double completion).

Run 2 (25s arm) — panic in <25s (panic-race2.txt), attribution is direct:

panic: assertion "ccb->ccb_xa.state != ATA_S_PUT" failed in ahci_put_ccb at ahci.c:3321
ahci_put_ccb() at ahci_put_ccb+0xde
ahci_put_ccb() at ahci_put_ccb+0xde          <-- double put
ahci_ata_complete_disk_rw() at +0xec
ahci_port_intr() at ahci_port_intr+0x790
ahci_poll() at ahci_poll+0x50
ahci_cam_probe() at ahci_cam_probe+0xfa      <-- THE UNLOCKED RE-PROBE
Debugger("panic")

The unlocked XPT_SCSI_IO re-probe polls a command whose completion was already processed elsewhere and puts the ccb back a second time — the finding's worst-case mode ("one ccb slot with two simultaneous owners"), caught by the serial/state guards.

Control (identical load, NO arming, 70s): no panic, no extra probes

(1 Found DISK line total = boot probe), 14,650 pass CCBs all clean, guest healthy. The NEED_IDENT branch is the differentiator.

3. Honest limits

• The trigger state was injected by the rig. On unmodified hardware the branch is only armed by ahci_pm.c:876 (PM hard reset), and QEMU has no SATA PM device model. Natural reproduction therefore requires physical PM hardware; everything downstream of the arming is production code on production state.
• With the PM absent, at->at_probe for a direct-attached disk is only GOOD/FAILED after boot, so the unlock can also not fire via disk hot-plug events on this guest.

4. Fix

fix.diff (now the combined validated diff; the DF-4203 hunk is the ap_lock bracket, identical to the first-round proposal): bracket the re-probe with ahci_os_lock_port()/ ahci_os_unlock_port(), mirroring the dispatch 60 lines below. On the patched kernel the identical armed race ran clean (no panic, probes serialized), while the control load stays healthy.

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.