DF-4721 — vinum launch_requests() walks the freed request group when the last group element is a skipped XFR_BAD_SUBDISK rqe and the drive completes inline (md) → kernel panic

What this proves

The DESIGNED degraded RAID-5 write (ONE down data subdisk — no reborn trickery, no revive, no waitlist) builds the request group as

rqe[0] = parity read                 (launched)
rqe[1] = good data block             (launched)
rqe[2] = down data block, XFR_BAD_SUBDISK   (skipped at launch)

The last LAUNCHED element is rqe[1]; rqe[2] is a TRAILING skipped element. With md (malloc) backing, biodone() runs inline inside dev_dstrategy(), so rqe[1]'s completion runs complete_rqe() -> complete_raid5_write() (XOR + phase-2 data write + parity write), whose own inline completions drive rq->active to 0 and freerq() the entire request while launch_requests() is still inside its launch loop (sys/dev/raid/vinum/vinumrequest.c:395-440). The loop then reads rqg->rqe[2].flags and rqg->next (:408-409) from the freed group; kmalloc's freelist pointer overwrites rqg->next and the loop dereferences garbage:

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
Stopped at launch_requests+0xc2: movq (%rax),%rax

Reproduced 2/2 baseline runs (once via the plain designed-degraded write with rv.p0.s2 down, once via DF-4714's two-reborn trigger — identical signature). This is the "at least one further lifetime defect in the relaunch path" that DF-4482's verification predicted after its two waitlist fixes failed to stop that panic: this arm needs no revive and no waitlist at all — just a degraded RAID-5 write whose trailing rqe is a skipped BAD_SUBDISK, on any drive completing synchronously in strategy (md; also plausible with other stacking).

Trigger

Same array as DF-4714. sh ../DF-4714/setup_vinum.sh; vinum setstate -f down rv.p0.s2; ./trigger (single 32KB write at volume sectors [128,192)) → panic within milliseconds.

Fix validation

fix.diff snapshots rqg->next before any firing and bounds the launch loop to the last non-BAD rqe (precomputed), so no group memory is read after an inline completion can free it. Applied + kernel rebuilt: write succeeds (correct degraded semantics), readback matches, no panic (run.patched.log step 3); DF-4714's panicking trigger now gets a clean EIO instead.