# DF-3677 — VERDICT

**status: inconclusive (logic bug, source-certain; no MPT RAID hardware on guest)**

## Root cause

`mpt_action()` maps the RAID-physical-disk target id to a real bus-0
TargetID for every function *except* three:

```c
/* sys/dev/disk/mpt/mpt_cam.c:3292-3302 */
	if (raid_passthru &&
	    ccb->ccb_h.func_code != XPT_PATH_INQ &&
	    ccb->ccb_h.func_code != XPT_RESET_BUS &&
	    ccb->ccb_h.func_code != XPT_RESET_DEV) {          /* <-- RESET_DEV excluded */
		if (mpt_map_physdisk(mpt, ccb, &tgt) != 0) { ... CAM_DEV_NOT_THERE ... }
	}
```

and `mpt_start()` performs the mapping itself for I/O
(`mpt_cam.c:2104-2112`), but the XPT_RESET_DEV case does not:

```c
/* sys/dev/disk/mpt/mpt_cam.c:3342-3359 */
	case XPT_RESET_DEV:
		...
		(void) mpt_bus_reset(mpt, tgt, lun, FALSE);       /* tgt = raw path id */
```

`tgt` is the *phydisk-bus* id (0..MaxPhysDisks-1, exported on bus 1,
`mpt_cam.c:3634-3638`), but `mpt_bus_reset()` issues the TMF on **channel
0** (`mpt_scsi_send_tmf(..., 0 /* channel */, tgt, ...)` via
`mpt_cam.c:2279-2287`), where the same numeric id denotes a **RAID
volume**. The result of `XPT_RESET_DEV` on a physical disk is a
TARGET_RESET of the unrelated volume that happens to share the number —
resetting every I/O in flight to that volume — or a reset sent to a
nonexistent target. `mpt_map_physdisk()` exists precisely to translate
(`mpt_raid.c:806-819`: `*tgt = mpt_disk->config_page.PhysDiskID`).

Impact: wrong-device reset (availability/data-integrity for the volume's
in-flight I/O: unit attentions, failed writes reported to fs layers).
Severity Low: requires a RAID-capable MPT controller, a userland reset of a
hidden physdisk (camcontrol reset on the phydisk pass node), and the volume
id space to overlap.

## Fix

```diff
--- a/sys/dev/disk/mpt/mpt_cam.c
+++ b/sys/dev/disk/mpt/mpt_cam.c
@@ -3291,7 +3291,7 @@
 	if (raid_passthru &&
 	    ccb->ccb_h.func_code != XPT_PATH_INQ &&
 	    ccb->ccb_h.func_code != XPT_RESET_BUS &&
-	    ccb->ccb_h.func_code != XPT_RESET_DEV) {
+	    ccb->ccb_h.func_code != XPT_RESET_DEV) {	/* keep: mapped below */
 		if (mpt_map_physdisk(mpt, ccb, &tgt) != 0) {
 			ccb->ccb_h.status &= ~CAM_SIM_QUEUED;
 			mpt_set_ccb_status(ccb, CAM_DEV_NOT_THERE);
@@ -3342,6 +3342,14 @@ mpt_action(struct cam_sim *sim, union ccb *ccb)
 		} else {
 			xpt_print(ccb->ccb_h.path, "reset device\n");
 		}
+		if (raid_passthru && mpt_map_physdisk(mpt, ccb, &tgt) != 0) {
+			ccb->ccb_h.status &= ~CAM_SIM_QUEUED;
+			mpt_set_ccb_status(ccb, CAM_DEV_NOT_THERE);
+			xpt_done(ccb);
+			return;
+		}
 		(void) mpt_bus_reset(mpt, tgt, lun, FALSE);
```

## Guest verdict

inconclusive — no MPT RAID controller on the QEMU guest; the mapping
mismatch is proven by reading the three code sites against each other.

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