# DF-4403 — Reserved request slots and CAM ccbs leaked on error paths (permanent AEN/param channel death; hung ccb)

## What
Four error paths in `sys/dev/raid/tws/tws_cam.c` abandon resources:

1. `tws_send_scsi_cmd()` `:841-844`: `req->data = kmalloc(TWS_SECTOR_SIZE,
   M_NOWAIT|M_ZERO)`; on failure returns ENOMEM while `reqs[1]` (the AEN
   fetch slot) stays `TWS_REQ_STATE_BUSY` forever — reserved slots are gated
   by `state` alone and are never on FREE_Q (`tws.c:631-632, 760-769`), so the
   asynchronous-event channel is permanently dead: no AEN ever fetched again
   (each `tws_aen_complete` re-arms via `tws_fetch_aen`, `tws_cam.c:472-476`).
2. `tws_set_param()` `:868-872`: same for `reqs[3]` — the parameter channel
   dies; `tws_aen_synctime_with_host` and shutdown `tws_init_connect` paths
   degrade.
3. `tws_execute_scsi()` `:807-810`: the ccb timeout callout is armed at
   `:807` and `tws_map_request()` may fail (e.g. `bus_dmamap_load` ENOMEM /
   EFBIG); the error is returned to `tws_action` (`:271-272`, trace only)
   without `xpt_done(ccb)` and without releasing the request — the request
   slot is off FREE_Q forever (it is only re-queued by completion paths), the
   ccb is never completed, and because the request was never submitted it is
   not on BUSY_Q either (`tws_submit_command` inserts, `tws_hdm.c:326-330`),
   so even the reset drain (`tws_drain_busy_queue`, `tws_cam.c:616-643`) can
   never complete it: **permanent ccb leak + hung upper-layer transaction**
   (its callout eventually fires `tws_timeout` → full controller reset for a
   software failure).
4. `tws_get_param()` `:918-921`: same slot-stranding pattern for `reqs[3]`
   when the sector kmalloc fails (`req->cb == NULL` there, so nothing can
   ever complete it).

## Impact
Progressive driver degradation → CAM resource exhaustion → I/O DoS on the
adapter under sustained memory pressure; loss of AEN delivery (array
events/alarms silently stop). Requires kmalloc/dmamap failure — Low severity,
but the leaks are permanent (no recovery path).

## Status
QEMU guest has no 3ware HBA → inconclusive; each leak path proven from source.