DF-2877 — kdmsg_iocom_reconnect() kill-wait deadlocks unkillably when the

old peer neither writes nor closes (no fp_shutdown escape)

What this pack contains

• dfpeer.c — hold mode: attaches and parks holding the kernel's peer socket open with no traffic.
• run_f4.sh — attach #1 parks; attach #2 (DIOCRECLUSTER) wedges; the wedged process is in state D with wchan clstrkl and survives kill -9 (verified live: STILL_ALIVE_UNKILLABLE).

Root cause

kdmsg_iocom_reconnect (sys/kern/kern_dmsg.c:139-144) sets KILLRX and waits for the old reader/writer threads with a non-PCATCH lksleep loop. The old reader is parked inside fp_read() on the old peer socket and only observes KILLRX at the top of its loop, so it never exits until the peer sends data or closes. Unlike kdmsg_iocom_uninit (:283-294), which fp_shutdown()s the pipe after 10 seconds, reconnect has no escape: the calling thread (any DIOCRECLUSTER — e.g. the second of two hammer2 service daemon connects after a partial restart, or any root-held fd handoff) blocks forever in an unkillable kernel sleep, and the disk's iocom stays half-killed for all future attaches.

Reachability on a stock system: verified that the boot-time hammer2 service daemon DIOCRECLUSTERs every disk with a pipe (sbin/hammer2/cmd_service.c:898); any second connect to a connected disk while the old pipe is idle wedges. Triggering requires the ability to open the disk device (SYSCAP_RESTRICTEDROOT), hence severity Low.

Build & run (root)

cc -O -Wall -o /tmp/dfpeer dfpeer.c
sh run_f4.sh          # ends with STILL_ALIVE_UNKILLABLE
# cleanup: kill the 'hold' instance -> EOF releases the wedge

On the fix kernel, attach #2 blocks ~10s, then the old fp is shutdown, the ioctl completes, and the process is killable throughout.

DF-2877 VERDICT

Status: reproduced (dos — unkillable kernel deadlock of the

DIOCRECLUSTER caller; disk iocom blocked for all future connects)

Guest: DragonFly 6.5-DEVELOPMENT X86_64_GENERIC (env.txt).

What was run

run_f4.sh: 1. attach #1: dfpeer hold /dev/vbd0 240 — attaches via DIOCRECLUSTER and parks with the kernel's peer socket open, no traffic (the old reader thread parks inside fp_read on this socket), 2. attach #2: dfpeer openwr /dev/vbd0 3 — the ioctl wedges inside kdmsg_iocom_reconnect's kill-wait loop, 3. kill -9 the wedged process → still alive, state D, wchan clstrkl (ps output captured in run log; live proof: STILL_ALIVE_UNKILLABLE).

Root cause

sys/kern/kern_dmsg.c:139-144: the kill-wait sleeps with flags 0 (no PCATCH → signals never interrupt; the ioctl never returns) and there is no fp_shutdown escape, unlike kdmsg_iocom_uninit (:283-294) which shitcans the pipe after 10 s. The old reader only checks KILLRX at the top of its loop, so a silent-but-open peer socket pins it inside fp_read forever.

Stock relevance (observed on this guest): the boot-time hammer2 service daemon DIOCRECLUSTERs every disk with a pipe (sbin/hammer2/cmd_service.c:850-901; all *-msgrd/*-msgwr threads exist from boot). Any second connect to an already-connected disk whose old pipe is idle wedges — including a reconnect attempt by a restarted daemon while the old daemon's threads are still parked.

Triggering requires opening the disk device (SYSCAP_RESTRICTEDROOT in diskopen, sys/kern/subr_disk.c:78-80), hence severity Low; but the effect is an unkillable process plus a dead iocom for that disk.

Fix validation

fix.diff (10-second retry counter, then fp_shutdown of the old fp — mirroring kdmsg_iocom_uninit) applied, kernel rebuilt, PoC re-run: attach #2 blocks ~10 s, then completes normally; process is killable throughout (run.fix.log).