DF-3951 — mlx_start() wedge path leaks mlx_busycmds (slot-count never decremented) and leaves the DMA map loaded

Severity: Low · CWE-772 / resource-accounting · hardware-gated (controller must stop accepting mailbox writes)

Bug

When the controller refuses every mailbox write (the 100000-iteration spin at mlx.c:2089-2097 fails), mlx_start() revokes the slot on the error path:

    sc->mlx_busycmd[mc->mc_slot] = NULL;          /* mlx.c:2107 */
    device_printf(sc->mlx_dev, "controller wedged (not taking commands)\n");
    mc->mc_status = MLX_STATUS_WEDGED;

but forgets sc->mlx_busycmds--. The only decrement in the driver is in mlx_done() (mlx.c:2146), which only runs for commands the controller completed. Each wedged submission therefore permanently inflates mlx_busycmds:

• mlx_getslot() (mlx.c:1966) refuses new commands once mlx_busycmds >= limit - 4 (normal) / >= limit (priority) — after a handful of wedge events all future I/O returns EBUSY forever: mlx_startio() breaks out (mlx.c:1739-1742), every read/write to the mlx drives fails, and even MLX_COMMAND management ioctls are locked out. No recovery path exists short of a reboot.

Additionally, on the mlx_startio() wedge path the command's DMA map is never unloaded: mlx_unmapcmd() is only called from mlx_complete() (mlx.c:2194) for commands that reached the work queue; the WEDGED command never did, and mlx_completeio() (mlx.c:1796-1800 → 1839) releases the command with mc->mc_data still mapped. The recycled command's map is then re-loaded by a later mlx_mapcmd() without an intervening unload.

Build / Run / Expected

cc -O2 -Wall -o mlx_ioctl_trigger mlx_ioctl_trigger.c
./mlx_ioctl_trigger wedge /dev/mlx0   # against a controller that stopped taking commands
dd if=/dev/mlxd0 of=/dev/null bs=64k count=1   # -> EBUSY permanently

Expected on hardware: after N wedge events, dd fails and all mlx I/O returns EBUSY until reboot. On this guest: ENOENT (no HBA) — hardware-gated.

Fix

Decrement mlx_busycmds alongside the slot clear (fix.diff).

DF-3951 — Verification Verdict

Status: inconclusive (hardware-gated; source-certain) Impact demonstrated: none (expected: permanent EBUSY lockout of all controller I/O) Confidence: certain (source), runtime untestable (no DAC960 HBA)

Source proof

1. mlx_getslot() increments sc->mlx_busycmds when handing out a slot — sys/dev/raid/mlx/mlx.c:1981-1982.
2. Sole decrement: mlx_done() at mlx.c:2145-2146, reachable only via a completion posted by mlx_findcomplete() (mlx.c:2137).
3. Wedge path: mlx_start() at mlx.c:2107 clears sc->mlx_busycmd[slot] without touching mlx_busycmds (grep-verified: no other decrement in the driver). Consequence: mlx_getslot() at mlx.c:1966 permanently fails once the leaked count reaches limit - 4; every subsequent mlx_startio() breaks at mlx.c:1739-1742 → all disk I/O EBUSY, no recovery until reboot.
4. Secondary defect on the same path: the WEDGED command never enters sc->mlx_work (TAILQ_INSERT only on queue success, mlx.c:2094), so mlx_complete() (mlx.c:2194) never calls mlx_unmapcmd() for it; mlx_startio()'s wedge handler (mlx.c:1798-1799) calls mlx_completeio() directly → command recycled (mlx.c:1839) with mc->mc_data still bus_dmamap_load()ed (mlx_mapcmd, mlx.c:2038).

Impact: permanent controller I/O lockout (availability) — operator/root gated ioctls or ordinary I/O against a wedged HBA; no memory-safety impact.

Guest result

Trigger compile-tested (BUILD_RC=0, DragonFly 6.5-DEVELOPMENT); runtime ENOENT — no Mylex hardware. Honest: inconclusive / source-certain.

Fix validation

fix.diff adds the missing decrement. Not runtime-testable here → fix_status: not_testable.

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.