# DF-4541 — VERDICT

**Status: untested** (no HighPoint hardware on the audit guest; path is
root-only sysctl). The finding is established by code trace, not by
execution.

## Code trace (why this is certain without hardware)

* `hpt_set_array_state()` `AS_INITIALIZE_START`:
  sys/dev/raid/hptmv/ioctl.c:572-591.
  * ioctl.c:580 — `hpt_queue_dpc((HPT_DPC)hpt_rebuild_data_block,
    pAdapter, pVDevice, VERIFY);` — **VERIFY**, not INITIALIZE.
  * ioctl.c:583-589 — waits on `rf_initializing`, which is only set by
    `hpt_rebuild_data_block` case `INITIALIZE` (ioctl.c:720-727); the
    VERIFY case sets `rf_verifying` (ioctl.c:729-736).  Wait can never
    succeed → 80 s of 1-tick tsleep polling (`timeout >= hz*80`).
  * ioctl.c:616 — `return 0` after the timeout: success despite no-op.
* Correct comparators: `AS_VERIFY_START` queues VERIFY (ioctl.c:540);
  CREATE_ARRAY `CAF_CREATE_R5_ZERO_INIT` queues INITIALIZE
  (ioctl.c:392); `AS_INITIALIZE_ABORT` waits on `rf_initializing`
  (ioctl.c:595) — i.e. the rest of the driver agrees INITIALIZE is a
  distinct operation.

## Why not run

* The only user entry is `sysctl dev.hptmv.status` write
  (hptproc.c:614-617, CTLFLAG_RW) → root-only.
* Requires a HighPoint RocketRAID controller with a functional RAID1/5
  array; the QEMU guest has none (`gIal_Adapter == NULL`; a sysctl
  write on the guest panics via the already-known DF-1853 NULL-deref
  before reaching this code).

## Impact assessment

Logic/data-hygiene bug + per-call 80 s kernel-thread stall, root-only,
hardware-bound: **Low**.  Bucket: base:dev.

## Recommended fix

```diff
--- a/sys/dev/raid/hptmv/ioctl.c
+++ b/sys/dev/raid/hptmv/ioctl.c
@@ -577,7 +577,7 @@ hpt_set_array_state(DEVICEID idArray, DWORD state)
 			unlock_driver();
 
-			hpt_queue_dpc((HPT_DPC)hpt_rebuild_data_block, pAdapter, pVDevice, VERIFY);
+			hpt_queue_dpc((HPT_DPC)hpt_rebuild_data_block, pAdapter, pVDevice, INITIALIZE);
 			unlock_driver();
 
 			while (!pVDevice->u.array.rf_initializing)
```

Additionally, the wait loops (ioctl.c:494-500, 519-525, 543-549,
562-568, 583-589, 602-608, 430-436) should `return -1` (or otherwise
report failure) when they time out instead of falling through to
`return 0`.

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

(No fix.diff for this item: documented recommendation only - see Fix above.)