DF-5094 — vinum: unbounded daemon instantiation + pid-blind abdication

(multi-consumer double-free hypothesis REFUTED by MP-token serialization)

Build / Run (root on the DragonFly guest)

kldload vinum
cc -O2 -pthread -o /tmp/df5094 /tmp/df5094_multidaemon.c   # = build.sh
/tmp/df5094 90                                              # = run.sh

What to expect

• Corruption hypothesis (double Free of one daemonq element by two concurrent daemons): does NOT reproduce. Two runs pushed 27,798,967 + 18,707,189 elements through 3 concurrent daemon threads; no panic, no slab messages, guest healthy. Root cause of the refutation: vinum_ops is not D_MPSAFE, so every vinum ioctl (including the whole vinum_daemon() loop) runs under the MP token (kern_device.c:570-577), and every daemonq producer holds the same token — the queue is fully serialized despite the crit-only guard. See VERDICT.md.
• Residual defect (reproduces): N daemons run concurrently (abdication at vinumdaemon.c:83 is pid-based; same-process threads are never ousted, and a busy daemon never re-checks); the daemon threads park in a non-PCATCH tsleep, so after the producers stop the process survives kill -9 (D-state), and the module cannot be unloaded.

Files

df5094_multidaemon.c — 3 daemon threads (VINUM_DAEMON ioctl) + 4 producer threads (VINUM_SAVECONFIG ioctl storm). run.log/run.2.log — decisive runs. threadstate.txt — live wchan capture (2× vinum, 1× mp_token) + kill -9. dmesg.txt, env.txt, build.log — environment and compiler evidence.

DF-5094 — vinum: unbounded daemon instantiation, pid-blind abdication; the

plausible multi-consumer double-free is REFUTED on current DragonFly (MP token)

What was claimed and what held

Claim investigated (pass-2 extension of DF-2103, which itself says "No mem corruption"): VINUM_DAEMON (vinumioctl.c:296) starts vinum_daemon() with no single-instance check; the "abdication" guard (vinumdaemon.c:83) compares curproc->p_pid with the daemonpid stamp and only runs after tsleep returns — so threads of one process (same pid) can never oust each other, and a busy daemon never re-checks. With the dequeue at vinumdaemon.c:89-94 guarded only by crit sections (no cross-CPU serialization of the queue itself), two concurrent daemons should double-dequeue one struct daemonq element and Free() it twice (vinumdaemon.c:177) → kernel heap double-free.

What is real (certain, demonstrated on the guest): * any number of concurrent daemons can be instantiated — 3 ran at once; * abdication is pid-based and lazy: same-process daemons are NEVER ousted; * the daemons are permanent: P_SYSTEM + non-PCATCH tsleep → the host process becomes unkillable (kill -9 leaves a D-state process — captured in threadstate.txt), aggravating the DF-4760 stop-wedge.

What is refuted (certain, demonstrated on the guest): * the memory corruption. Every path that touches daemonq executes while holding the MP token: - consumers: vinum_daemon() runs inside the VINUM_DAEMON/VINUM_FINDDAEMON ioctl → dev_doperate_ops() takes get_mplock() because vinum_ops is NOT D_MPSAFE (vinum.c:58-70, kern_device.c:570-577). tsleep releases the token while asleep and reacquires it before returning, so the whole daemon loop body (dequeue, switch, Free) is token-serialized. - producers: save_config() from ioctls (token via the ioctl), the daemonrq_ioerror producer complete_rqe() explicitly get_mplock() (vinuminterrupt.c:75), daemonrq_closedrive from set_sd_state ioctls, and the daemonrq_return stop element from free_vinum() (module-event path). So the crit-only queue protection is redundant-but-safe in the current tree: the MP token is the real lock.

Empirical: two adversarial runs (3 daemon threads + 4 VINUM_SAVECONFIG producer threads on a 6-CPU guest) pushed 27,798,967 + 18,707,189 ≈ 46.5M elements through the concurrent consumers with zero panics, zero slab/freelist corruption messages, guest healthy afterwards (run.log, run.2.log). Live thread states show the serialization directly: two daemons asleep on wchan vinum, the third blocked on mp_token (threadstate.txt).

Reproduce (root on the DragonFly guest)

kldload vinum
cc -O2 -pthread -o /tmp/df5094 /tmp/df5094_multidaemon.c   # or ./build.sh
/tmp/df5094 90                                               # or ./run.sh

Expected on this kernel: 3 concurrent daemons consume the storm cleanly, the process becomes unkillable at exit, no panic — i.e. the corruption claim does NOT reproduce; the unbounded-daemon / unkillable-process behavior DOES.

Notes

• Note for DF-2103: the same MP-token invariant calls into question pass-1's "cross-CPU races lose/leak requests" impact on the current tree for the token-holding producers; the lost-wakeup liveness half of DF-2103 (check-then-tsleep with no interlock, vinumdaemon.c:74-88) remains valid — token serialization does not fix lost wakeups.
• If vinum is ever converted to D_MPSAFE (or the daemon moved out of the ioctl context) without replacing crit sections with a real spinlock/mutex, this becomes the double-free described above — the PoC here is then the trigger.

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