DF-4300 — vkbd_dev_close check-then-sleep TASK handshake can miss the drain task's wakeup while pinning the kernel mplock

Finding

vkbd_dev_close() (sys/dev/misc/vkbd/vkbd.c:307-308) waits for the drain task with a plain check-then-sleep loop:

    while (state->ks_flags & TASK)
        VKBD_SLEEP(state, ks_task, "vkbdc", 0);   /* tsleep, PCATCH */

and the task side (vkbd_dev_intr, vkbd.c:627-632) clears the flag and wakes the sleeper after draining:

    kbd_intr(kbd, NULL);
    state->ks_flags &= ~TASK;
    wakeup(&state->ks_task);

There is no interlock (no tsleep_interlock/critsec between the flag test and the sleep), so a wakeup that lands between the close path's flag test and its tsleep() insertion is lost: close sleeps indefinitely.

Aggravating factor: vkbd's dev_ops is not D_MPSAFE (vkbd.c:179-190, flags 0), so d_close is dispatched under the kernel mplock (sys/kern/kern_device.c:174-189, dev_needmplock() at :119-121), and DragonFly's tsleep() does not release the mplock (sys/kern/kern_synch.c — no mplock handling). A close that blocks here pins the mplock, stalling every other non-MPSAFE dev_d*() call in the system until the sleeper receives a signal (PCATCH) or forever.

Status

Not reproduced live: ~90,000 open/write/close cycles racing the drain task against close (vkbd_wedge.c, log in ../DF-4302 session) never observed a stuck close — the check→tsleep window is empirically very narrow. The race is code-real (no interlock) but stochastic; filed as speculative.

Fix

Use an interlocked sleep (test-and-sleep under a critical section / tsleep_interlock pattern), or have the task hold off clearing TASK until it can re-check sleepers; simplest: perform the wait with the standard tsleep_interlock()+tsleep() pairing around the flag check.

DF-4300 verdict

Reproduced?

Not reproduced (not_reproduced — honest stochastic outcome, not a refutation of the code pattern).

Empirical hammer: vkbd_wedge.c ran ~90,000 open("/dev/vkbdctl") → write(2 scancodes) → close() cycles in forked children so that close always raced the just-enqueued drain task (the exact precondition for the missed wakeup). No close blocked; the window between the while (state->ks_flags & TASK) test (vkbd.c:307) and tsleep insertion proved too narrow to hit in that many attempts on this 6-vCPU guest.

Root cause (path:line)

• sys/dev/misc/vkbd/vkbd.c:307-308 — check-then-sleep, no interlock.
• sys/dev/misc/vkbd/vkbd.c:627-632 — task clears TASK + wakeup unconditionally after kbd_intr().
• sys/kern/kern_device.c:119-121,174-189 — vkbd dev_ops flags 0 → d_close dispatched under the mplock.
• sys/kern/kern_synch.c — tsleep() contains no mplock release, so a blocked close holds the mplock.

Impact if hit

The closing thread sleeps holding the mplock → all non-MPSAFE device entry points system-wide block → broad device-I/O stall (disk/net on any non-MPSAFE drivers), recoverable only by signalling the sleeper (PCATCH makes tsleep return; the loop then re-checks TASK, which is now clear, and close completes). Root-triggered (the /dev/vkbdctl node is 0600 root:wheel), narrow window → Low severity, speculative confidence.

Fix

Interlocked sleep around the TASK check (see fix.diff).

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.