DF-4214 — RAID reply handler deregistration is not refcounted: detaching one mpt(4) controller breaks the other's RAID completion path

• File: sys/dev/disk/mpt/mpt_raid.c (lifetime; interacts with sys/dev/disk/mpt/mpt.c:402-478)
• Lines: 135 (static id), 291–297 (attach register), 338–340 (detach deregister)
• Class: shared-resource lifetime bug (CWE-666/CWE-404) → request leak / unkillable hang on surviving controller
• Preconditions: ≥2 mpt(4) RAID controllers; one detached (hot-removal/kldunload path) while the other runs RAID activity

Root cause

mpt_reply_handlers[] is a global table shared by all mpt controllers (mpt.c:119). Registration is deliberately idempotent: a second controller registering the same function gets the same slot back (mpt.c:417-426: "If the same handler is registered multiple times, don't error out"). Deregistration, however, is unconditional and un-refcounted (mpt.c:466-471) — and mpt_raid_detach() calls it for the shared raid_handler_id (mpt_raid.c:338-340, raid_handler_id is a file-static at mpt_raid.c:135).

So: ctrl1 attach → slot X = mpt_raid_reply_handler; ctrl2 attach → reuses X (no count); ctrl1 detach → slot X cleared; ctrl2 keeps issuing RAID actions with MsgContext = index | raid_handler_id (mpt_raid.c:616).

Consequence on the surviving controller

Late replies for ctrl2's RAID actions now dispatch to mpt_default_reply_handler (mpt.c:480-495), which only prints and returns — it never completes, dequeues, or frees the request. Every RAID action on ctrl2 then:

• times out after the 2 s busy-poll (mpt_wait_req, sleep_ok=FALSE) and is either leaked forever on request_pending_list (mpt_verify_mwce / mpt_verify_resync_rate paths), or freed-while-pending (the DF-4211 bug),
• drains the 512-entry request pool until mpt_get_request(sleep_ok=TRUE) blocks forever in non-interruptible mpt_sleep — wedging the RAID thread and any thread touching the vol_member_wce/vol_resync_rate sysctls (unkillable local DoS from what should be a scoped device event).

Verification status

untested — hardware-gated (needs two MPT Fusion HBAs; guest has none, env.txt). Source-certain.

Fix

fix.diff: reference-count the personality's registration (raid_handler_refs) and only deregister when the last controller detaches.

VERDICT — DF-4214

status: untested (hardware-gated) · impact: request leak → unkillable hang on surviving controller (dos) · confidence: certain (source)

Not runnable here: requires ≥2 LSI MPT Fusion HBAs (env.txt shows none). Mechanism proven from source:

• Global handler table + idempotent register: mpt.c:119, mpt.c:417-426.
• Un-refcounted deregister: mpt.c:466-471.
• mpt_raid.c:135 static raid_handler_id; attach register at mpt_raid.c:291-293; detach deregister at mpt_raid.c:338-340 — with two controllers attached, the first detach clears the shared slot.
• Surviving controller's RAID actions encode that handler id (mpt_raid.c:616); after the slot is cleared, mpt_intr dispatches to mpt_default_reply_handler (mpt.c:809-821 → mpt.c:480-495) which never completes/frees the request → ETIMEDOUT after the 2 s busy poll (mpt.c:1356-1361) → leaked requests pinned on request_pending_list (mpt_verify_mwce mpt_raid.c:977-981 leaves them), pool exhaustion, and mpt_get_request sleeping forever (mpt.c:1273-1276) — wedging the RAID thread and sysctl writers in non-interruptible sleep.

Severity Low (unusual configuration: two RAID cards + detaching one). Fix diff refcounts the registration; not runtime-validated (no hardware) → 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.