Kernel: every kernel panic halts and panic recovery is deleted; delete usbd; open the no-kernel-threads track (K1)

[Japabu]

Every kernel panic now halts the machine, including a panic inside a syscall, and all of the kernel's panic recovery is deleted. The branch also opens the owner's no-kernel-threads track and does its first stage (K1): usbd is deleted.

The ruling this lands

The owner ruled:

• A kernel panic means a kernel invariant broke, so it always halts, then reboots or holds the panel under the existing panic policy.
• A Ring 0 fault is a kernel bug and halts, whatever syscall or thread is current.
• A Ring 3 fault kills only its own process, as before.
• "The kernel never crashes from userland" is kept by refusing bad input at the boundary, not by surviving panics.

This reverses the old rule that a recoverable panic ended only the process that caused it.

What is deleted, and why

• The panic handler's decision. The percpu::in_syscall() branch is gone. So are try_recover_from_panic (x86 and the aarch64 stub) and recover_or_halt. The handler now always captures, flushes and calls halt_all_cpus.

• Poisoned threads. Deleted:

  • kernel/src/sched/poison.rs, the per-CPU POISONED bank and poison_tid;
  • schedule_no_return;
  • process::PoisonWake and zombify_poisoned;
  • toyos-proclife/src/poison.rs and Watch::thread, whose one caller was the poison path;
  • the poison-overwrite feature, together with its loom model kernel-loom/tests/poison_set.rs and its red in src/ci.rs.

  The idle loop's reap_poisoned becomes reap_finished. It only collects exits that have been published, behind the same ReapGate.

• The scheduler's (Ready(_), Dead) edge. Its one stated user was schedule_no_return. The only production edge into Dead is Running → Dead.

• The panel's survived-panic path. Deleted: panic_console::discard_capture, CaptureAccess::discard, CaptureLatch::owned_by, and the loom model of a discard. The latch's release stays, because capture_into still uses it. Its loom model is renamed a_released_latch_hands_the_snapshot_to_the_next_captor.

• blame.

  • toyos_userbound::{blame, Blame, Faulted} are deleted. The ring of a trap now decides whose fault it is. That ring is the opaque Ring, which is built only from cs.
  • fatal_exception kills the process on a Ring 3 fault and halts on anything else.
  • A recursive fault always halts. A Ring 3 frame can only arrive with this CPU already in Fatal/Panic if the kernel left that state set, and that is a kernel bug.

• Ring 0 demand paging. page_fault_handler now sends a not-present fault to process::handle_page_fault only for a Ring 3 frame: if is_user && process::handle_page_fault(..). It used to do that for any fault taken while a thread was current. A Ring 0 fault falls through to fatal_exception, which halts before anything is mapped into the current process. handle_page_fault's kernel-thread refusal became unreachable and is deleted.

• SYS_DEBUG action 2's one-shot arming. It existed to refuse a second call into a lock that a recovered panic had stranded.

• deaf_window's unconditional sti. It now holds an IrqGuard. The unconditional enable was there because panic recovery could leave IF clear. Machine::irq_guard/type IrqGuard, the trait method deaf_window does not use, are deleted together with their five impls (kernel/src/arch/x86_64/hw.rs, kernel/src/arch/aarch64/hw.rs, toyos-sched/src/cpu.rs, toyos-sched/sim/src/hw_impl.rs, toyos-sched/loom/tests/loom_retire.rs); deaf_window calls the concrete crate::arch::IrqGuard::close() directly and never went through the trait. The review named only the first three; the aarch64 kernel and the loom build are what caught the other two.

• The aarch64 percpu::in_syscall stub. It has no caller now.

• The kernel-thread panic policy. OnPanic, a row's recoverable word and panic_recovers_here are deleted.

• K1. usbd is deleted: kernel/src/drivers/xhci/usbd.rs, its start(), the usbd-panic actuator, and usbd in the test lists. The track is issues/kernel/the-kernel-still-creates-threads.md (kind: track), with stages K2–K6.

The panic path's reset does not wait on the console wire

panic_reboot::reboot_now resets through acpi::reset_now, not acpi::reboot. The log is already drained by that point, and acpi::reboot opens with serial::flush_final, which spins PANIC_LOCK_SPIN_LIMIT (100,000,000 iterations of try_lock and pause) on the console wire. A CPU this panic stopped may hold that wire, and a stopped CPU never releases it, so that wait could only run out. The limit being a count and not a time is filed as panic-path/the-panic-lock-spin-limit-is-a-count-its-comment-calls-a-second.md.

This change is measured green, but what it fixes is not proven. At f9700b90, syscall_panic_halts went red once: the guest printed returning this machine to firmware, QEMU reported no reset in the harness's wait, and the test took 98 s at a 2.96x liveness width. The held-wire arm below does not reproduce that. With the wire held and the old acpi::reboot path, the row stays green (EXIT=0). It takes 27 s, against 7–8 s for the fixed path at the same head, so the held wire's spin costs about 19–20 s at a 1.50x width and still resets inside the 37 s budget. A held wire alone therefore does not account for that red, and nothing measured here explains it. No deterministic red arm exists on the old path: flush_final's spin is bounded, so a held wire delays the reset and does not stop it.

The syscall-death rows also subscribe to QMP before they write the command (power::watch_the_bound), the way machine_reboot does. QMP delivers no event that was emitted before its client connected.

Tests

• Four Nightly rows, all run through power::syscall_death_resets:

  Row	SYS_DEBUG action	Must say
  syscall_panic_halts	PANIC	the panic, Syscall: num=92, the user backtrace
  syscall_fault_halts	NULL_READ on the 2 MiB-aligned window inside a 4 MiB .bss array the child never touches	KERNEL PANIC: read unmapped address at <that address>, Syscall: num=92, the user backtrace
  lock_across_switch_halts	LOCK_ACROSS_SWITCH	the tripwire, with check_tripwire_attribution scoping its panicked at to syscall/dispatch.rs
  heap_over_ceiling_halts	HEAP_OVER_CEILING	exceeds MAX_HEAP_ALLOC

  Each row boots panic-reboot-fast with QMP and runs test_rs_test_panic_child <action>. The verdict is QEMU's guest-reset inside the fast bound plus the reset allowance, the same reading klogd_death_resets takes (klogd_panic_halts, klogd_fault_halts). The two share died_and_reset. When a row's own check fails, its error carries the guest's capture. These guests put the 16550 on stdio, so no uart-*.log exists for a red run to keep.

• syscall_fault_halts carries the demand-paging claim.

  • NULL_READ is a Ring 0 read of the address its caller passes. The kernel records SYS_DEBUG: a Ring 0 read of <addr> first, and check_ring0_read_unmapped reads the address from that record. It is a record and not the child's own line because the panic path drains records, while a program's line is still in userland when the read ends the machine. check_ring0_read_unmapped also refuses address 0: a child that regressed to calling syscall::debug(action) for every action, dropping the window argument, reads address 0 and must red rather than pass.
  • The address has to be demand-paged. An anonymous mmap does not qualify: sys_mmap maps its pages when it makes it, and the region is RegionKind::Mapped. A Ring 0 read of one takes SMAP's fault on a present page and says protection violation. RegionKind::Anonymous regions are the loader's, a segment's pages past its file bytes. So the child reads the aligned window inside static mut UNTOUCHED: [u8; 4 MiB]. In the built child, UNTOUCHED is the first 0x400000 bytes of .bss at 0x7e2c8, in a PT_LOAD segment with 5656 file bytes and 4200196 memory bytes, so the window holds no other object and no file bytes.
  • A kernel that demand-paged that window for Ring 0 would re-execute the read into SMAP's fault (+smap on both x86-64 CPU models, src/arch.rs) and say protection violation instead. This row replaces the read of address 0.

• panic_recovery is folded into fault_gates. fault_gate_child gains a pf arm (read_null). check_fault_gates requires its SEGFAULT tid= header and fault_gate_child::read_null in the backtrace. Deleted: panic_recovery.rs, check_panic_recovery, its timeout and duration rows, and segfault_child, which nothing else ran.

• heap_ceiling_recovery is renamed heap_ceiling_bounds. Its over-ceiling arm moved to heap_over_ceiling_halts. Its "the heap still works after recovery" arm is deleted.

• screen_recoverable_untouched and screen_survived_panic_not_blamed are deleted. They tested a panic that survives, and none can now.

• test_panic_child needs an action. Every caller names one.

• Harness prose that relied on recovery is cut:

  • serial::Died::Kernel;
  • qemu::ceiling_verdict's doc;
  • await_guest's scoping comment;
  • Ppm::identical_to's doc;
  • needs_actuators and suite_split.

• Unpriced in tests/test-durations: syscall_panic_halts, syscall_fault_halts, lock_across_switch_halts, heap_over_ceiling_halts, klogd_panic_halts, klogd_fault_halts and heap_ceiling_bounds. The committed profile is measured on a CI runner (committed_durations_path), and a dev host's TCG times are not written into it. fault_gates is priced at 31 from before it had the eighth arm. panic_recovery's row is deleted.

Issues

• Deleted, because the defect went with its code:
  • panic-path/panic-holding-process-table-hangs.md;
  • panic-path/the-discards-refusal-branch-is-exercised-by-nothing.md.
• Filed:
  • panic-path/a-crash-report-can-name-a-syscall-that-already-ended.md. It covers both migration directions and process::handle_fault's unbracketed syscall_num();
  • panic-path/the-panic-lock-spin-limit-is-a-count-its-comment-calls-a-second.md;
  • build/idle-stack-guards-returned-arm-reads-a-line-nothing-writes.md;
  • build/a-sysroot-cloned-during-a-toolchain-rebuild-never-gets-its-cargo.md;
  • build/a-guest-with-no-virtio-keeps-no-serial-when-its-run-reds.md: lane::keep_serial keeps only uart-*.log, so a red run of a guest whose 16550 is on stdio keeps an empty lane. The harness owns it;
  • isolation/interrupt-entry-keeps-a-ring-3-ac-flag.md;
  • panic-path/a-syscall-panic-reset-the-guest-announced-and-qemu-never-saw.md: the f9700b90 red above, filed once the wire-held measurement refuted the only proposed mechanism.
• Edited:
  • nothing-charges-kernel-memory-to-a-process.md: an unbounded grower now ends the machine;
  • a-deliberate-wedge-…md: the recovery paragraph is deleted;
  • the two wall-4 issues: the clauses citing the deleted recovery arm are deleted;
  • the-capability-end-state-is-twelve-answers.md: its kernel-resident-workers section is deleted, since the track states the opposite rule;
  • the-kernel-is-small-interrupts-post-and-threads-wait.md: usbd is gone from it.

in_syscall stays

in_syscall stays, because only the crash report's Syscall: lines read it now. Reading the syscall frame at the top of the thread's own kernel stack instead does not work: that frame cannot tell a syscall's frame from a Ring 3 interrupt's without trusting words userland chose. An interrupt puts SS and CS in the slots where a syscall's frame holds the user's rsp and rdi. The per-thread bit that would be left needs new per-thread state written on every syscall, not one rule in one function. The issue above records this.

Gates

At fe7c7a6c, which is this branch after merging origin/main at 41ad548c:

Gate	Exit
cargo run -- --clippy, including the three aarch64 kernel invocations	EXIT=0, "10 invocations clean"
cargo test --lib	EXIT=0 (379 passed, 1 ignored)
cargo test --workspace --exclude toyos-build (toyos-sched, its sim and loom included)	EXIT=0
cargo test --test toyos-build -- --list (builds the C corpus and every Rust test binary, checks the redlist, boots nothing)	EXIT=0
cargo run -- --build-only	EXIT=0

Measured by the orchestrator at fe7c7a6c: syscall_fault_halts --nightly EXIT=0; with the demand-paging mutant EXIT=1, "expected KERNEL PANIC: read unmapped address at 0x10000200000: the read did not fault as unmapped"; with the child's window multiplied by 0 (the address-0 arm) EXIT=1, "expected the demand-paged window, not the null read"; dump_nmi_probe --nightly EXIT=0; the Fast tier 393 passed, 1 failed, the one being lan_mdns_answer (a macOS socket path over SUN_LEN in the harness, fixed by its own PR). Earlier heads' guest results below stand where this round did not touch their paths.

Negative controls and the independent oracle (run by the orchestrator)

The independent oracle is QEMU's own SHUTDOWN event, read through qemu::QmpShutdown. It is the hypervisor reporting that the guest reset, not the guest's serial.

Each patch is applied with git apply --check then git apply, and reversed with git apply -R. Each mutated tree passes cargo run -- --clippy (EXIT=0).

Arm	Patch	Command	Result
Ring 0 demand paging	demand-paging-ring0.patch: if (is_user || percpu::current_tid().is_some()) && process::handle_page_fault(..)	cargo test --test toyos-build -- --nightly syscall_fault_halts	EXIT=1 at eb19f5b5 (553r5-demandpaging-syscall_fault_halts.log). The kernel says KERNEL PANIC: read protection violation at 0x10000200000; the check says expected \KERNEL PANIC: read unmapped address at 0x10000200000`: the read did not fault as unmapped at 0x10000200000`. The machine still resets, so the red comes from the named assertion.
The held wire on the old path	wire-held-red.patch: reboot_now goes back to acpi::reboot, with the wire held first (core::mem::forget(serial::try_wire()))	cargo test --test toyos-build -- --nightly syscall_panic_halts	EXIT=0 at 8e525da4, 27 s. A measurement of the wait, not a red arm; see above.
The held wire with the fix	wire-held-green.patch	same	EXIT=0 at 8e525da4, 8 s.
R2: a Ring 3 fault halts	R2-ring3-halts.patch: if false && ctx.ring().is_user() in fatal_exception	cargo test --test toyos-build -- --nightly fault_gates	EXIT=1 at 8e525da4.

Green arms, orchestrator-run: at 8e525da4, cargo test (Fast) — 393 of 394 passed, the one red lan_mdns_answer (path must be shorter than SUN_LEN), a harness socket-path defect #560 fixes and red the same way on #536, #541, #554, #555 and #559 (#560's own run of it is EXIT=0); and, under cargo test --test toyos-build -- --nightly <row>, each of syscall_panic_halts, lock_across_switch_halts, heap_over_ceiling_halts, klogd_panic_halts, klogd_fault_halts, heap_ceiling_bounds, panic_reboots, panic_key_holds, fault_gates and disk_backtrace EXIT=0 (553r4-*.log); syscall_fault_halts alone was EXIT=1 there (553r4-syscall_fault_halts.log), fixed by 355e0d64. At eb19f5b5, rerun under the same nightly command: syscall_fault_halts, syscall_panic_halts, lock_across_switch_halts and heap_over_ceiling_halts each EXIT=0 (553r5-green-*.log).

Unsure / left outside the fence

• What made syscall_panic_halts red at f9700b90 is unknown, as the section above says.
• NULL_READ keeps its name while it reads any address. A rename changes toyos-abi/src and so the sysroot key, which is outside this brief.
• The recursive-fault path changed. A recursive fault on a Ring 3 frame now halts where it used to kill the process. No test stages it.

Net against origin/main (41ad548c): +630 −1782. Production +130 −1061 (kernel +102 −503, toyos-userbound +8 −226, toyos-proclife +5 −158, kernel-loom +8 −136, toyos-sched +4 −31, toyos-abi +2 −2, src +1 −5); tests +243 −568; issues +256 −153; CLAUDE.md +1, the orchestrator's.

🤖 Generated with Claude Code

[Japabu]

Review of 5a7964dd against origin/main. PR CI host at this head: success (run 36339673529). The guest tests are measured in the PR body at f63ac32d, and the head differs from it only in CLAUDE.md. Net: kernel +34 −133, tests +23 −86, issues +45, CLAUDE.md ±1.

Panic path, every context. A user thread is unchanged from main: panic_recovers_here() returned None for any non-kthread, so the handler already fell to in_syscall(). The same holds for early boot (PERCPU_READY), for idle (no pid), for an IRQ taken from Ring 3 or idle, and for a Ring 3 fault. A Ring 3 fault never reaches the panic handler; blame returns Process and the process is killed. The only contexts that change are the ones the branch intends. A panic on a kernel thread, or in an IRQ handler that runs while one is current, now halts. On main, an IRQ-handler panic that landed while iod/usbd was current poisoned that thread and the machine carried on. in_syscall() compares identity, so a kernel thread running while a user syscall is parked on the same CPU does not inherit that syscall's recovery. The line is right for panics. It is not the line the fault path draws; see the first NOTE.

BLOCKER

• PR body "Independent oracle: none" / tests/toyos.rs:13395: a high-risk change to the panic path names no independent oracle, and CLAUDE.md requires one. A cheap one is already in the tree. Boot klogd-panic with panic-reboot-fast and qmp: true, then require QEMU's own reset through qemu::QmpShutdown inside PANIC_FAST_SECS + RESET_ALLOWANCE, the way tests/common/power.rs panic_reboots does. That is the hypervisor's report, not the guest's serial. M1 (|| sched::kthread::current_is_kernel_thread() at kernel/src/main.rs:181) must turn it red too.

NOTE

• toyos-userbound/src/fault.rs:102, kernel/src/arch/x86_64/idt/exceptions.rs:120. This predates the branch and is outside its fence. A Ring 0 #PF on a user-half address is ProcessThroughKernel whenever any tid is current, and it then goes to try_recover_from_panic. A kernel thread's null dereference (cr2=0, is_user_addr(0) holds) therefore poisons the thread and the machine carries on. For klogd that is exactly the silent mute its old Halt row claimed to prevent. An IRQ handler's null dereference while a user thread is current kills that innocent process instead of halting. Panics are judged by in_syscall() and faults by on_a_thread: two answers to one question. File it as a defect. The candidate fix is to feed percpu::in_syscall() in as the blame input, after measuring that no Ring 0 user-address access happens outside a syscall.
• Negative control: I accept M1 in place of the whole revert. The whole revert is green by construction, because klogd's row was Halt on main. Only iod's outcome moved, and no test can see it. But the branch makes a per-thread panic policy unrepresentable: the handler at kernel/src/main.rs:181 reads no per-thread state, and bringing one back means adding a type, which review sees. M1 red, and M1 plus the old verdict green, are the right pair.
• tests/test-durations:257: still prices klogd_panic_halts at two boots (16658), and it is now one. Re-price it, then re-tier it under src/tiers.rs or say why it stays Nightly.
• tests/toyos.rs:13424: this is a second copy of screen_late_panic's arm-line derivation (tests/toyos.rs:5941). Make it one fn.
• issues/kernel/the-kernel-still-creates-threads.md:43 (K5): Storage: file servers for DATA, the log and the boot volume; the kernel's NVMe and FAT go #536 does not remove a kernel thread; it swaps one. Its head (wt/toyos-fsd, kernel/src/main.rs:592) spawns a new kthread::spawn("probe", probe, 0, OnPanic::Recover) to host sched_operation_nesting and sysret_ss_probe, which ride iod today (kernel/src/iod.rs:20-29). That spawn also conflicts with this branch. The track owes a stage for those two probes' host.
• issues/kernel/the-kernel-still-creates-threads.md:40 (K4): nothing plans to move the console. issues/kernel/every-driver-is-still-in-the-kernel.md never mentions the console or klogd, and its exception criterion ("stays in the kernel only if the kernel needs it while userspace is dead") keeps the console in. K4 is blocked on a decision nobody holds, which makes it an owner question.
• c14fc9af carries the usbd.rs deletion and does not compile alone, so a bisect through the merge hits a broken commit. It cannot be fixed without rewriting history; recorded here only.
• CLAUDE.md:39: under "A snapshot", the orchestrator's sentence states the ruling as present fact while klogd, iod, lognest and logstorm exist. This is the orchestrator's call.

REMOVE

• kernel/src/sched/kthread.rs:4-6 "A panic inside one halts the machine: …": rewritten module prose. It misleads, because a fault inside one does not halt (first NOTE), and the contract is the handler.
• kernel/src/sched/kthread.rs:113 "Before enqueue_new: from that call the task can run and panic.": its reason went stale with this branch. No row reader is on the panic path any more.
• kernel/src/main.rs:667 "After klogd so its spawn log has a drainer.": a rewritten comment that is not load-bearing. Records commit to their shards whoever drains them.
• tests/toyos.rs:1234: a rewritten row comment that no longer says why the row is Nightly.
• tests/toyos.rs:13420 "The verdict is the line only halt_all_cpus writes.": false. panic_reboot::arm is also called from the reentry and early-panic branches (kernel/src/main.rs:135, :149).
• issues/kernel/the-kernel-still-creates-threads.md:23-28: the pasted grep output. Its line numbers move with every landing, and Storage: file servers for DATA, the log and the boot volume; the kernel's NVMe and FAT go #536 and Kernel: a kill never waits on its victim — the last thread out tears its process down #549 each change it. Keep the command.
• issues/kernel/the-kernel-still-creates-threads.md:32: K1 is done when this merges.
• issues/kernel/the-kernel-still-creates-threads.md:37-38 "move to a userland test program whose threads emit through the syscall path, or": refuted for lognest by kernel/src/log/nested.rs:45 (IF is clear for a whole syscall).
• issues/kernel/the-kernel-still-creates-threads.md:40-42 "under issues/kernel/every-driver-is-still-in-the-kernel.md … Blocked on that track moving the console.": that track carries no such move.
• issues/kernel/the-kernel-is-small-interrupts-post-and-threads-wait.md:24-25 "The thread reserved to own the controller, usbd, only parks.": that thread is deleted.
• issues/kernel/the-kernel-is-small-interrupts-post-and-threads-wait.md:141 "owned by its thread, then": the kernel-thread half of stage 5, which the ruling forbids. Lines 65, 115 and 128-140 name step 10's userland usbd ("the whole xHCI moves", "usbd killed mid-batch"). That usbd is consistent with the ruling, and those lines stay.
• issues/kernel/every-wait-in-this-kernel-is-a-spin.md:95-98: this bullet's invariant, that a kernel-thread panic is recoverable and there are three threads, is now false. :31 stays: it is a true record of what completions: the duration kinds, the one park site, the sleep lock, and the daemons on it — pipeline 2's first half #91 landed.
• issues/kernel/the-capability-end-state-is-twelve-answers.md:352-405: the whole "Kernel-resident workers" section. Its rule (:354-359) contradicts the ruling. Its census and verdict (:361-396) name usbd, OnPanic and three threads. Its PID-backed paragraph (:398-404) describes the machinery the track deletes. The track is now the one home for this.

SEND BACK

[Japabu]

Review of 73e00d78 against origin/main. Gate: PR CI host at this head is green (run 36347325470, conclusion success). --ci host boots no guest. The only QEMU runs are 14 targeted tests at 6897bff9, taken before the merge of c5518949. Reviewed anyway because the brief asks for the arms owed. Net: production +105 −1002, tests +179 −482, issues +145 −148.

Round 1 BLOCKER, no independent oracle for the kernel-thread halt: CLOSED. klogd_panic_halts and klogd_fault_halts take QEMU's guest-reset over QMP. M1 is red: nokthread-k1-r2/arm-m1.log, EXIT=1, "QEMU never reported stopping". MB is red: arm-mb.log, EXIT=1.

BLOCKER

• (no guest run at this head) — The branch turns two things into a machine halt: every Ring 0 fault on a user address, and every panic reachable from a syscall. PR CI runs no guest test, and only 14 hand-picked tests ran, on a pre-merge tree. A shared-boot test that stayed green only because the kernel killed its caller now halts the shared boot. Only the whole suite finds that. Owed at the next head, with EXIT and log: cargo test, then cargo test --test toyos-build -- --nightly syscall_panic_halts syscall_fault_halts lock_across_switch_halts heap_over_ceiling_halts klogd_panic_halts klogd_fault_halts heap_ceiling_bounds panic_recovery.
• kernel/src/arch/x86_64/idt/exceptions.rs:504 — R2 (a Ring 3 fault halts) is unmeasured, and it is the other half of the ruling. Apply nokthread-r3/R2-ring3-halts.patch (if false && ctx.ring().is_user()) onto the head. cargo test --test toyos-build -- panic_recovery fault_gates must go red. Reverse the patch and it must go green.
• kernel/src/arch/x86_64/idt/exceptions.rs:447 — On high-risk code, no test can fail on the claim "a Ring 0 fault maps nothing into the current process". NULL_READ reads address 0, which lies in no region. The minimal test:
  • Turn DA::NULL_READ into a Ring 0 read_volatile of the address the caller passes (debug_with(action, addr), reading a2).
  • test_panic_child takes a 4 MiB anonymous mapping it never touches and prints reading {addr:#x} for base + 2 MiB, a window inside a live region. Then it calls the action.
  • syscall_fault_halts requires KERNEL PANIC: read unmapped address at {that addr:#x}, Syscall: num=92 and the reset.
  • Negative control: - if is_user && process::handle_page_fault(fault_addr, frame.error_code) { / + if (is_user || percpu::current_tid().is_some()) && process::handle_page_fault(fault_addr, frame.error_code) { must turn it red.
  • Under that mutant the machine still resets. The window gets mapped, and the re-executed read takes SMAP's #PF PRESENT on this +smap CPU. So the reset alone stays green, and the assertion must name unmapped and the address.
  • This row replaces address 0, so one row carries both claims.

NOTE

• toyos-sched/src/task.rs:278 — Delete (Ready(_), Dead). The branch deleted its one stated reason (schedule_no_return), and the only production edge into Dead is Running → Dead (task.rs:1168). A legality table that admits an edge nobody takes is a weaker check on the scheduler.
• tests/common/power.rs:950 — syscall_death_resets writes the command before died_and_reset connects QmpShutdown (:901). The guest's 5 s fast bound is the only margin before the SHUTDOWN it must not miss. Connect before the write, the way machine_reboot does.
• kernel/src/arch/x86_64/percpu.rs:762 (brief item 3) — Keeping in_syscall is acceptable here: nothing decides on it any more, and it is recorded. The filed issue has half the defect, though:
  • leave_syscall on the CPU a migrated syscall finishes on clears whatever bracket that CPU holds, even another parked thread's. So a genuine syscall death afterwards prints no Syscall: line.
  • process::handle_fault (process.rs:1676) prints the per-CPU syscall_num() with no bracket at all.
  • There is a way that makes the issue go away. syscall_entry already pushes the user rsp, the user rip (rcx) and the number (rdi) at the top of the thread's own kernel stack, the one kernel_rsp names and switch moves with the thread. Reading them there deletes OFF_SYSCALL_RIP/OFF_SYSCALL_NUM and the identity compare. The one per-thread bit left is whether the top frame is a syscall's. Add both directions and handle_fault to the issue.
• tests/toyos-rust-tests/src/bin/panic_recovery.rs — What is left is a subset of fault_gates plus disk_backtrace's symbol checks. Add a pf arm to fault_gate_child/fault_gates, then delete panic_recovery.rs, check_panic_recovery and its runtime row (tests/toyos.rs:18290). If it stays, its name and "all panic recovery tests passed" are false.
• kernel/src/sched/dump.rs:387 — deaf_window's unconditional sti has lost its one reason, which was panic recovery leaving IF clear. Either an IrqGuard is right now, or there is a reason the code has to show.
• kernel/src/sched/driver.rs:715 — metal-panic-probe fired from the idle loop only because a syscall panic used to recover (the comment the branch deleted). Nothing keeps it there now. It is outside the fence, so leave it.
• tests/test-durations — klogd_panic_halts, klogd_fault_halts, the four *_halts syscall rows and heap_ceiling_bounds are unpriced.
• CLAUDE.md:40 — The branch deletes the blank line between Kernel and Userspace daemons, which joins the two paragraphs. This is the orchestrator's file.

REMOVE

• toyos-abi/src/syscall.rs:793 "Armed once per boot." — the arming is deleted.
• kernel/src/drivers/panic_console/mod.rs:261 "until recovery"
• kernel/src/drivers/panic_console/mod.rs:292 "whose fall-through skips recovery — the only path that never paints."
• tests/toyos-rust-tests/src/bin/process_lifecycle.rs:8 "or panic recovery" — no such teardown exists.
• tests/common/power.rs:913-915 "a recovered klogd … a halting and a recovering kernel both write" — describes a kernel that cannot exist.
• issues/isolation/interrupt-entry-keeps-a-ring-3-ac-flag.md:20 "instead of faulting into blame" — blame is deleted.
• tests/toyos-rust-tests/src/bin/heap_ceiling.rs:114-116 "Measured against the old code: …" — chronology in a paragraph the branch rewrote.
• kernel-loom/tests/reap_gate.rs:29-30 "Verified 2026-08-17, both ways round." — a date in a rewritten sentence, verifying a message that changed.
• kernel/src/sched/dump.rs:387 — a comment rewritten to a bare assertion.
• toyos-sched/src/hw.rs:104-107 — rewritten so that "both exits" now carries one exit's reason.
• kernel/src/quiesce.rs:28-29 "klogd and iod" — a rewritten list that K3–K5 move.
• issues/kernel/deferred-release-outlives-its-syscall.md:240-241, issues/kernel/every-wait-in-this-kernel-is-a-spin.md:160-162, :384-385 — 73e00d78 corrected these citations instead of deleting them.
• PR body "## Kept from the earlier rounds" — review chronology in main's record.
• PR body "Unsure", first bullet — the sysroot narrative (22:08, "every harness run from this worktree") belongs to its issue, not to main's record.

SEND BACK

[Japabu]

Round 5 review of eb19f5b5 against origin/main (e5ffe950).

Gate.

• PR CI host at eb19f5b5 is queued and has no conclusion yet (run 36353717547). The previous CI run, at 8e525da4, was cancelled.
• The local host gates at eb19f5b5 all exited 0 (nokthread-r5/gates.summary): clippy, --lib, --workspace --exclude toyos-build, --list and --build-only.
• Every guest result below is the orchestrator's run.
• Net: +582 −1737. Production +118 −902, tests (tests/, kernel-loom/tests) +246 −682, issues +217 −153, CLAUDE.md +1.

Round-3 BLOCKERs

• No guest run at the head: CLOSED.
  • At 8e525da4, cargo test (Fast) exited 1. It passed 393 of 394, and the one red is lan_mdns_answer (path must be shorter than SUN_LEN). That test is red the same way on the runs of Storage: file servers for DATA, the log and the boot volume; the kernel's NVMe and FAT go #536, clang from our own LLVM builds ToyOS's C, and toyos-cc is gone #541, xHCI: every report that moves a port's belief leaves it to be read #554, tests: a pty tethers QEMU and the judge's servers to the harness #555 and netd: a listener's socket that left Listen is handed over or listens again, and a refused accept leaves its owner a wake #559, and A boot's sockets are a TempDir under /tmp, reclaimed like all scratch; disable partition_claim_departure and i8042_mouse #560's run of it exits 0.
  • At 8e525da4, each of these --nightly rows exited 0: syscall_panic_halts, lock_across_switch_halts, heap_over_ceiling_halts, klogd_panic_halts, klogd_fault_halts, heap_ceiling_bounds, panic_reboots, panic_key_holds, fault_gates and disk_backtrace.
  • At eb19f5b5, syscall_fault_halts, syscall_panic_halts, lock_across_switch_halts and heap_over_ceiling_halts each exited 0 (553r5-green-*.log).
  • panic_recovery no longer exists. Its arm is now fault_gates' pf.
• R2: CLOSED. R2-ring3-halts.patch at 8e525da4 makes --nightly fault_gates exit 1 with STALLED … the guest had said nothing for the last 15s, meaning the machine stopped at the first Ring 3 fault. Without the patch the row exits 0.
• A Ring 0 fault maps nothing: CLOSED.
  • At eb19f5b5 the row is green, exit 0.
  • demand-paging-ring0.patch makes it exit 1. The log shows #PF PRESENT: cr2=0x10000200000 … err=0x1, then KERNEL PANIC: read protection violation at 0x10000200000, then QEMU resets. So the red comes from the named assertion, not from the reset.
  • My round-3 prescription, an anonymous mmap, was wrong, and round 5's correction holds:
    • sys_mmap allocates a PageAlloc and map_ranges it into a RegionKind::Mapped region (kernel/src/syscall/vm.rs).
    • Only the loader creates RegionKind::Anonymous (loader/mod.rs:160, :494).
    • The red at 0xfffec00000 in both arms at 8e525da4 was that eager mapping.
  • The .bss layout checks out in child-readobj.txt:
    • .bss sits at 0x7e2c8 with size 0x4000ec. It is in the PT_LOAD at 0x7ccb0, whose 5656 file bytes end exactly at 0x7e2c8 and whose memory size is 4200196.
    • So the window 0x200000–0x400000 holds only .bss. The other 0xec bytes of .bss cannot reach it, whether they come before UNTOUCHED or after it.
    • The dump does not show that UNTOUCHED is the first 0x400000 bytes, but nothing depends on that.

BLOCKER

(none)

NOTE

• PR body, the "Ring 0 demand paging" row and the "Green arms" paragraph — both still say "owed at eb19f5b5" — the measurements now exist (the 553r5 lines). The claim stands only on the body, so the body must carry each command, exit code and log.
• PR CI host at eb19f5b5 — no conclusion yet — it must be success before the merge.
• syscall_panic_halts went red once at f9700b90: the guest announced its reset and QEMU saw no reset — the cause is unexplained, and it is recorded only in the PR body. File it under issues/panic-path/ with that run's log as evidence and an exit condition. Until it is explained, it is a panic-path defect.
• PR body, "What Kernel: a kill never waits on its victim — the last thread out tears its process down #549 must drop" — the list is not exact:
  • The sched/kthread.rs bullet is wrong. Kernel: a kill never waits on its victim — the last thread out tears its process down #549's hunk adds open_selftest, which reads row.task.load(..). Here ROWS is [AtomicU64], so Kernel: a kill never waits on its victim — the last thread out tears its process down #549 must adapt it to row.load(..), not drop it.
  • Missing: Kernel: a kill never waits on its victim — the last thread out tears its process down #549's toyos-proclife/src/teardown.rs module doc and claim_teardown doc ("the idle loop's sweep of a main thread that died in panic recovery", "exit/kill/poison path").
  • Missing: its process.rs teardown_code doc ("exit/kill/poison path").
  • Missing: its main.rs hunk, whose context line is drivers::xhci::usbd::start();.
  • This is a merge instruction for another PR, so post it on Kernel: a kill never waits on its victim — the last thread out tears its process down #549 rather than in main's record.
• toyos-sched/src/hw.rs:89,104-105 — type IrqGuard and fn irq_guard, re-documented as "Has no caller in either world" — with the panic-recovery reason gone, this is dead code. Delete it together with its impls at kernel/src/arch/x86_64/hw.rs:36,53-55, toyos-sched/src/cpu.rs:2501,2507 and toyos-sched/sim/src/hw_impl.rs:129,156.
• tests/toyos.rs:3192 check_ring0_read_unmapped accepts the address 0 — so the row loses its power if the test child regresses. For example, test_panic_child calling syscall::debug(action) for every action reads null and stays green, and so does demand-paging-ring0.patch on top of it. Refuse addr == 0; that mutant must then red on syscall_fault_halts.
• kernel/src/sched/dump.rs:387 — no guest run covers deaf_window's IrqGuard — its one test is dump_nmi_probe (Nightly), and it is in none of the runs. Owed: cargo test --test toyos-build -- --nightly dump_nmi_probe at the head.
• toyos-abi/src/syscall.rs:792 NULL_READ — the name is false now that the action reads the caller's address — a rename costs one sysroot rebuild, which is no reason to keep a false name.

REMOVE

• issues/panic-path/the-panic-lock-spin-limit-is-a-count-its-comment-calls-a-second.md:16-27 — it gives, as the cause of the f9700b90 red, a mechanism the PR body calls unproven and the held-wire arm did not reproduce. The defect stands on the code.
• same file :13-14 "and nobody has measured that on any machine this kernel boots" — false. wire-held-red measured it: 27 s against 7–8 s.
• same file :29 "the run above, and" — it dangles once :16-27 go.
• kernel/src/drivers/xhci/stop.rs:103 "written from acpi::reboot" and :638 "Called from acpi::reboot and acpi::shutdown and nowhere else" — both false. The panic path now reaches before_reset through reset_now alone.
• kernel/src/drivers/panic_console/mod.rs:291-292 "Called from the idle loop." — this only narrates the caller.
• tests/common/metal.rs:722 "and panic_recovery" — it cites a test the branch deleted.
• tests/toyos.rs:3141-3146 — the "N = 12 rounds of fault_gates + panic_recovery" provenance. It cites the deleted test, and measurement provenance does not belong in source.
• PR body, "Unsure": the 69e8dff5/c14fc9af bullet and the eb19f5b5 co-author bullet — commit chronology, not main's record.
• PR body, "Unsure": the metal-panic-probe bullet — it is neither filed nor load-bearing.

LAND AFTER NAMED CHANGES