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