DF-4896 — complete_rqe() volume error path abandons the request: recover_io() re-strategizes the bio but nobody frees the old request — full request leak (rq + rqg chain + malloc'd buffers + locked bufs) per errored volume I/O; VOL[].active accounting also leaked

Root cause (inspection-certain)

sys/dev/raid/vinum/vinuminterrupt.c:219-226:

if (rq->error) {            /* did we have an error? */
if (rq->isplex) {       /* plex operation,  (DF-4481) */
    ubio->bio_buf->b_flags |= B_ERROR;
    ubio->bio_buf->b_error = rq->error;
} else {            /* try to recover */
    di.rq = rq;
    queue_daemon_request(daemonrq_ioerror, di); /* let the daemon complete */
}
}

The daemon's only consumer of daemonrq_ioerror is recover_io() (sys/dev/raid/vinum/vinumdaemon.c:198-209):

void recover_io(struct request *rq) {
dev_dstrategy((cdev_t)rq->bio->bio_driver_info, rq->bio);
}

It re-strategizes the user bio; vinumstart() then builds a brand-new request. The OLD struct request — the whole rqg chain, every XFR_MALLOCED buffer (RAID-5 parity/group buffers, KBs each), and the XFR_BUFLOCKED buf locks taken in build_rq_buffer() — is never freed (freerq() is only called on the success path at vinuminterrupt.c:232 and in vinumstart's build-failure paths at vinumrequest.c:273/300).

Additionally VOL[rq->volplex.volno].active (incremented in vinumstart(), vinumrequest.c:231) is decremented only in the success branch (vinuminterrupt.c:229-230) — the error branch leaks the count too (currently a write-only counter; cosmetic but part of the same defect).

Amplification

If the failing subdisk has VF_RETRYERRORS set (the error path at :102/:113 then leaves the sd up), every daemon retry rebuilds, re-fails, re-queues: an unbounded retry loop leaking one complete request per iteration at I/O speed → kernel memory exhaustion + vinum daemon livelock. Without the flag, the sd is crashed by the error path and the retry fails cleanly (EIO) — leak is then bounded by the error rate (persistent hardware faults still leak unboundedly over time).

Trigger / PoC

Requires a component bio error at completion time (failing device). PoC sketch (trigger.sh, untested): RAID-5 volume per DF-4895 setup; loop writes; make one drive's device fail; observe M_DEVBUF growth via vmstat -m and the missing freerq (locked bufs accumulate).

Guest verification not possible: this guest's vinum drives sit on md (malloc) devices that cannot be made to fail I/O — re-verified this run (2026-09-24): gpt destroy/gpt remove under open vinum I/O leave the stale slice cdev serving requests with no error; no mdconfig failure-injection facility exists on the image. Same blocker as DF-4481 (its verdict recorded the same). Classification: untested, certain by inspection.

Fix (proposed; not applied)

Own the handoff: free the old request when the retry is issued.

--- a/sys/dev/raid/vinum/vinumdaemon.c +++ b/sys/dev/raid/vinum/vinumdaemon.c @@ -205,7 +205,13 @@ recover_io(struct request rq) / * Reissue the command. / - dev_dstrategy((cdev_t)rq->bio->bio_driver_info, rq->bio); + { + struct bio bio = rq->bio; + cdev_t dev = (cdev_t)bio->bio_driver_info; + if (rq->isplex == 0) + VOL[rq->volplex.volno].active--; / error path never drops it / + freerq(rq); / the old request is abandoned / + dev_dstrategy(dev, bio); / reissue under a new request / + } }

(severity Low: requires root-triggerable I/O errors / failing hardware; impact is unbounded kernel-memory + locked-buf leak per error.)