x86 has no requeue_thread_after_save() caller and no DEFERRED_REQUEUE, so wake_expired_timers()'s is_current_on_any_cpu arm has no owner there

[ryanbreen]

Summary

Scheduler::wake_expired_timers() has an arm that deliberately does not
enqueue a thread it has just published as Ready:

• it pops the expired timer-heap entry,
• publishes ThreadState::Ready,
• clears wake_time_ns,
• and returns without putting the thread on any ready queue,

on the documented assumption that either the running thread notices after its
own halt, or DEFERRED_REQUEUE picks it up. That arm is taken whenever
is_current_on_any_cpu is true — i.e. whenever the woken thread is still named
by some CPU's current_thread.

Both stated fallbacks are aarch64-only. DEFERRED_REQUEUE, and every caller
of requeue_thread_after_save(), live in
kernel/src/arch_impl/aarch64/context_switch.rs. x86 has zero of either. So on
x86 the enqueue in that arm is unowned: whether the thread ever runs again
depends entirely on the caller noticing for itself.

Status: latent, not demonstrated

Nothing reachable exercises it today, and this is explicitly not a claim
that a live wake is being lost on x86. The one caller that made the window
deterministic — sys_poll, which re-arms a 1 ms slice so its deadline has
essentially always expired by the time schedule() runs — was investigated
under #568 and the mechanism could not be demonstrated: the mutation offered as
proof did not separate, and an A/B battery on beast KVM (8 boots per arm,
differing only by the ordering hunk) showed zero poll-oracle failures on either
side. See docs/planning/green-program/sockets/EVIDENCE-2026-08-29.md §5 and §9.

What remains after that investigation is the structural asymmetry itself, which
is real regardless: an architecture-neutral scheduler path documents two
fallbacks that exist on one architecture only.

Why file it

Any future x86 caller that blocks with a short deadline lands in the same
arm with no owner for its enqueue, and the failure mode is silent — the thread
is Ready, in no queue, with no heap entry. The code reads as if a fallback
exists.

Suggested shape

Either give the arm an owner on x86 (the x86 equivalent of
requeue_thread_after_save() / DEFERRED_REQUEUE), or make the arm's comment
name the architecture its fallbacks belong to and refuse — loudly — when it is
reached on an architecture that has none. Silently relying on an absent
mechanism is the shape this campaign has been closing under the "unowned
delivery" heading (#669).

Disclosed by-catch from #568.

[ryanbreen]

Demonstrated, then fixed by construction — closing via fix/568-poll-wedge

This issue was filed as "latent, not demonstrated". That was wrong, and the
evidence that contradicts it was already in the tree when it was written: the
round-2 A/B battery's own preserved serials.

Counting threads that were silenced rather than threads that failed — a
thread whose last Saved kernel context for blocked thread N is followed by no
Restored kernel context for thread N, and which never exited — the round-2
battery reads:

round-2 battery, re-read	arm A — reorder OUT	arm B — reorder IN	arm M — pristine main
poll_tcp_oracle stranded	4/8	0/8	n/a (no oracle)
oracle verdict emitted at all	4/8	8/8, all PASS	n/a

Round 3 reinstated the reorder and proved it at scale at the merge-candidate
bytes. Interleaved A/B on beast breenix-x86 (KVM, -cpu host,
testing,external_test_bins) at kernel commit efe08b17; both kernels built
once from that commit, arms differing only by
kernel/src/task/scheduler.rs, boots alternating so host order effects cannot
favour either arm:

	reorder IN (merge candidate)	reorder reverted
boots	24	16
poll_tcp_oracle saved blocked and never restored	0/24	12/16
any thread stranded	0/24	13/16
oracle verdict emitted	24/24	4/16
panic or fault record	0/24	0/16

One-sided Fisher on 0/24 against 12/16 is 3.3e-7.

The mechanism this issue describes is exactly what was observed

wake_expired_timers() ran after the outgoing-thread disposition block. The
block reads the outgoing thread's state to decide whether to requeue it and
leaves a thread still marked BlockedOnTimer off the ready queue. Only then did
the wake run — and because this CPU has not yet selected a successor,
cpu_state[cpu].current_thread is still the outgoing thread, so the pop took
the is_current_on_any_cpu arm: published Ready, consumed the thread's only
timer-heap entry, and deliberately did not enqueue, on the documented
assumption that the running thread would notice after its halt or that
DEFERRED_REQUEUE would catch it. Neither holds for a thread being switched out
in that very call, and — this issue's whole point — neither exists on x86 at
all. The thread is left Ready, in no queue, with no heap entry.

sys_poll is the caller that made it deterministic: it re-arms a 1 ms slice, so
its deadline has essentially always expired by the time schedule() runs.

The fix

Wake first. The outgoing thread is already Ready when the disposition block
reads it, and the existing enqueue there takes ownership — the arm gets an
owner. The wake path's is_current_on_any_cpu guard is untouched, byte for
byte: this gives the wake an owner rather than relaxing the rule that
protects it. The asymmetry this issue names still exists as an asymmetry; what
is fixed is that schedule() no longer routes a thread into it with nobody to
catch it.

Commit efe08b17 on fix/568-poll-wedge. Evidence and every one of the 40
per-boot outcomes:
docs/planning/green-program/sockets/EVIDENCE-2026-08-29.md §5 and
docs/planning/green-program/sockets/AB-2026-08-29-round3.md.

Closing with the PR that lands that branch.

[ryanbreen]

Closed by the #568 landing PR

The fix is the wake_expired_timers()-before-outgoing-read reorder in
kernel/src/task/scheduler.rs, restored in efe08b17 in its original round-1
shape (git diff 07ba27c0 HEAD -- kernel/src/task/scheduler.rs is empty;
is_current_on_any_cpu is untouched).

It is proven by A/B on beast breenix-x86 under KVM, both arms built from the
same commit and differing only by that hunk (arm OUT is the same tree with
the patch reverse-applied), boots interleaved CAND,OUT,CAND,OUT so host order
effects cannot favour either arm:

arm	n	poll_tcp_oracle saved blocked and never restored
CAND (reorder in)	24	0
OUT (reorder reverted)	16	12

One-sided Fisher 3.2576e-07. Verdicts emitted 24/24 on the candidate arm,
TEST_TALLY 24/24, zero silent non-verdicts; no panic or fault record on any of
the 40 boots under a widened pattern set. The strand counts were recomputed
independently by review from the raw per-boot serials with its own census
implementation, and the mutation was re-run live from the round's own preserved
images (CAND 0/3, OUT 2/3, both stranded boots emitting no verdict).

Evidence in-repo: docs/planning/green-program/sockets/AB-2026-08-29-round3.md
and docs/planning/green-program/sockets/EVIDENCE-2026-08-29.md, with per-boot
serials from both arms under .../sockets/serials/.

Note that the instrument that made the strand visible -- poll_tcp_oracle --
is un-wired on x86 in the same PR for gate-compatibility reasons (#697). The
evidence above does not depend on it: the strand census in
scripts/x86-strand-census.sh reads the kernel's own context-switch record,
which is written whether or not the thread ever speaks again.

[ryanbreen]

Cross-link: the residual this issue's closing comment names explicitly — "The asymmetry this issue names still exists as an asymmetry; what is fixed is that schedule() no longer routes a thread into it with nobody to catch it" — is now tracked on its own as #699, filed by the 2:1 triage sweep with a fresh census at 782ab96f. This issue stays closed: its fix is landed and proven (0/24 vs 12/16, Fisher 3.3e-7), and #699 is about the routes it did not remove, not about that fix.