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