## fix-run log -- SAME harness on the patched #1 kernel
## guest: DragonFly 6.5-DEVELOPMENT #1: Sun Jul 12 14:16:09 UTC 2026  (single-fix)
## command:  kldload /tmp/df18_harness/df18_harness.ko
## result:   NO panic; duplicate DELETE handled gracefully (EALREADY, error 37)
##           (serial console capture from dfbsd-qemu/boot.log)

login: df18: loading; creating pipe-backed kdmsg iocom...
df18: iocom up; writing CREATE+2xDELETE for msgid=42
kdmsg: msgrx: duplicate DELETE
kdmsg: msgrx: state=0xfffff80117554a40 error 37
df18: harness completed without panic (KKASSERT is a no-op on non-INVARIANTS kernels).
kdmsg: iocom_uninit: shitcanning unresponsive pipe
kdmsg: Warning, write thread on 0xffffffff82600480 still terminating
... (iocom teardown noise -- unrelated to the bug; harness creates the iocom
     purely to exercise the receive path; teardown does not block) ...

## interpretation
The patched kernel reaches the new guard at kern_dmsg.c:956
(`if (state->rxcmd & DMSGF_DELETE)`) on the second DELETE, prints the
"msgrx: duplicate DELETE" diagnostic, sets error=EALREADY (errno 37), and
breaks out of the switch -- never reaching the KKASSERT at line 1076 (now
shifted to ~line 1090 by the insertion, but logically unchanged).

The kdmsg_msg_receive_handling caller sees error != 0, frees the message,
and treats EALREADY as a benign discard (kern_dmsg.c:689-690:
`if (error == EALREADY) error = 0;`).  No panic, no state corruption, the
duplicate DELETE is absorbed exactly as the finding's threat-model note
describes for non-INVARIANTS kernels.

The "iocom_uninit / Can't terminate" lines that follow are the harness's
own iocom teardown being noisy (the writer thread can't drain because the
read-side pipe is closed by the module's tsleep completing); they are NOT
the bug and are NOT a regression -- the unpatched kernel never got this far
(panic killed it first).