DF-2728 VERDICT — reproduced (panic, INVARIANTS kernel)

Status: reproduced. Impact: panic (INVARIANTS builds only). Confidence: certain.

How it was reproduced

Single KLD (df2728.c, this pack) driving the generic remote-schedule API on the audit guest (DragonFly 6.5-DEVELOPMENT #0, config X86_64_GENERIC with options INVARIANTS, 6 cpus, stock kernel, no modification of /sys):

1. MOD_LOAD (pinned to cpu0 via usched :1): lwkt_alloc_thread(NULL, LWKT_THREAD_STACK, cpu=1, TDF_NOSTART) creates a thread homed on cpu1, never started. The module sets td_preemptable = lwkt_preempt, td_pri = TDPRI_INT_MED (28) — exactly the state a sleeping hardware interrupt thread has (created by lwkt_create in kern_intr.c:329-336, descheduled in ithread_handler at kern_intr.c:966-967, td_critcount still 1 from lwkt_init_thread, sys/kern/lwkt_thread.c:453).
2. A userland spinner is pinned to cpu1 so the target cpu is executing a user thread (critcount 0, low td_pri) in userland when the IPI lands.
3. Mode 3 (control) first: plain lwkt_schedule() of the non-preemptable target — clean, no panic (console mode3: ok, no panic (control)).
4. Mode 1 (trigger): lwkt_schedule(g_td1) issued from cpu0. This is verbatim _lwkt_schedule()'s remote branch (sys/kern/lwkt_thread.c:1309-1311): lwkt_send_ipiq3(td->td_gd, lwkt_schedule_remote, td, 0).
5. cpu1 receives the hardware Xipiq (idle-spinning user thread → apic_vector.s:Xipiq → lwkt_process_ipiq_frame(frame) with gd_processing_ipiq == 1), dispatches lwkt_schedule_remote(frame), which — because frame != NULL && ntd->td_preemptable — executes crit_exit_noyield(td); _lwkt_schedule(ntd); crit_enter_quick(td); (lwkt_thread.c:1341-1344) and reaches lwkt_preempt() through _lwkt_schedule_post() (lwkt_thread.c:1278-1282).

Result (full text in panic.txt, console interleave garbles some bytes but every element is legible):

panic: assertion "gd->gd_processing_ipiq == 0" failed in lwkt_preempt at /usr/src/sys/kern/lwkt_thread.c:1026
cpuid = 1
lwkt_preempt() at lwkt_preempt+0x24d
lwkt_schedule_remote() at lwkt_schedule_remote+0x3f
lwkt_process_ipiq_core.isra.2() at lwkt_process_ipiq_core+0xff
lwkt_process_ipiq_frame() at lwkt_process_ipiq_frame+0x10d

The backtrace is exactly the designed remote-preemption pipeline; the assert at lwkt_thread.c:1026 rejects it.

Why the assert is wrong (not the path)

lwkt_schedule_remote()'s comment (lwkt_thread.c:1328-1334) states the design: "To allow preemption we have to drop the critical section so only one is present in _lwkt_schedule_post." The whole crit_exit_noyield() dance exists only to let lwkt_preempt() run from framed-IPI dispatch. On a non-INVariANTS kernel the sequence is fully balanced:

• critcount: Xipiq +1 (apic_vector.s:Xipiq incl TD_CRITCOUNT), remote −1 (crit_exit_noyield), _lwkt_schedule +1, restored +1 (crit_enter_quick), Xipiq −1.
• gd_intr_nesting_level: lwkt_preempt zeroes it around the switch (lwkt_thread.c:1045-1053) so the preemptor may block via lwkt_switch() without hitting the "switch from fast interrupt/IPI" panic (lwkt_thread.c:586-594), then restores.
• gd_processing_ipiq: held elevated across the preemption by lwkt_process_ipiq_frame (sys/kern/lwkt_ipiq.c:605), which is precisely the condition the assert forbids.

The first mode-1 run (before the spinner was started) landed on an idle/crit-elevated context, took the non-frame else branch, and printed mode1: returned WITHOUT panic (non-INVariANTS semantics: designed preempt) — the same call sequence completing cleanly when lwkt_preempt() declines (priority/crit checks at lwkt_thread.c:967-984) — showing the panic is solely the assert, not any state corruption. No corruption occurs: the assert fires before any state mutation of the interrupted thread beyond ntd->td_preempted = td bookkeeping, and the guest is deterministic-reset clean afterwards.

Reachability today

Unprivileged userland cannot reach it on the stock configuration: in-tree wakeups of interrupt threads are same-cpu (sched_ithd_intern() same-cpu branch kern_intr.c:590-594; live-lock systimer and emergency timer are cpu-local; sched_ithd_remote uses its own non-framed callback). The defect is latent but live for any KLD or driver that remotely schedules a td_preemptable thread via the exported lwkt_schedule() API, and it makes INVARIANTS kernels unable to exercise/validate the designed path at all.

Escalation assessment

Not applicable: INVARIANTS-only assert panic; stock kernels execute the path correctly with balanced accounting (verified by control run). No memory corruption primitive exists — the assert aborts before any unsafe state, and without INVARIANTS there is nothing wrong with the path at all.

Fix

fix.diff (assert removal, matches the fact that lwkt_switch()'s KKASSERT(gd->gd_processing_ipiq == 0) at lwkt_thread.c:576 remains valid — lwkt_preempt()'s switch bypasses lwkt_switch() for the interrupted thread, and lwkt_preempt()'s own intr-nesting zeroing handles the preemptor). Fix build not performed: Low/INVARIANTS-only finding; the control run demonstrates the identical path is clean when the assert is absent (non-INVariANTS semantics).