# DF-3950 — mlx_wait_command(): timeout counter never incremented → unkillable infinite wait

**Severity:** Low · **CWE-835** (loop without exit) · operator/root gated
(MLX_COMMAND path; also hit by MLXD_CHECKASYNC / MLX_REBUILDASYNC ioctls and
synchronous mlx_enquire calls)

## Bug

`sys/dev/raid/mlx/mlx.c:1655-1659`:

```c
    count = 0;
    /* XXX better timeout? */
    while ((mc->mc_status == MLX_STATUS_BUSY) && (count < 30)) {
	tsleep(mc->mc_private, PCATCH, "mlxwcmd", hz);
    }
```

`count` is declared (1646) and tested, but **never incremented** — the loop
condition `count < 30` is always true while the command stays busy. If the
controller never posts a completion (wedged HBA, pulled enclosure, firmware
hang), the calling thread sleeps 1s at a time forever. `PCATCH` lets a signal
interrupt each individual `tsleep`, but the loop immediately re-enters — the
thread can never make progress or exit; the ioctl never returns. The timeout
stamp `mc->mc_timeout = time_uptime + 60` set in `mlx_start()` (mlx.c:2086)
is documented "XXX not currently used" and indeed nothing consumes it
(grep-verified).

Contrast `mlx_poll_command()` (mlx.c:1689-1694) which correctly does
`count++ < 15000000`.

## Reachability

Any `MLX_COMMAND` passthrough whose firmware command never completes, or
`MLXD_CHECKASYNC`/`MLX_REBUILDASYNC` against a stuck controller. Requires a
wedged/unresponsive DAC960 — hence Low (privileged user + flaky hardware),
but the defect is unconditional in the code path.

## Build / Run / Expected

```sh
cc -O2 -Wall -o mlx_ioctl_trigger mlx_ioctl_trigger.c
./mlx_ioctl_trigger usercmd /dev/mlx0     # against a controller that hangs
```
Expected on hardware: ioctl never returns; `ps` shows the caller stuck in
`mlxwcmd` forever; SIGKILL does not reclaim the thread. On this guest:
ENOENT (no HBA) — hardware-gated.

## Fix

Increment `count` each iteration (and abort with EIO after the 30s budget),
matching the poll path; see fix.diff.