memory: the SMP crash is SMP-only, and what the font work cost

Two notes worth keeping out of the commit log because they are about where to
start next time rather than what changed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.claude/memory/schos-smp-userspace-corruption.md

@@ -0,0 +1,43 @@
+---
+name: schos-smp-userspace-corruption
+description: The intermittent "zsh jumps to rip 0" crash is SMP-only and still open — what has been ruled out, and the two facts worth starting from.
+metadata:
+  type: project
+---
+
+Open as of 2026-09-21. Roughly one to three processes per boot die with a
+user-mode fault they could not have caused themselves. It has been written off
+as "one zsh in ~5 boots makes a wild jump" for a while; it is more than that.
+
+**It is SMP-only.** Three boots at `-smp 1`: zero faults. Three at `-smp 2`:
+one, three, one. This is the single most useful fact about it and it was not
+known before.
+
+**It is not only zsh.** `schinitd` has taken one too, so it is not something
+about the shell.
+
+The two signatures seen, both from `kernel/arch/x86_64/trap.c`'s extended dump
+(which now fires for `rip` below a page or a faulting address near zero, not
+only for GP faults):
+
+- `trap 14 err 20 rip 0x0 addr 0x0` — an instruction fetch at zero. A process
+  does not branch there; it was handed a zero and followed it.
+- `schinitd: trap 14 err 4 rip 0x5d7b addr 0xffffffffffffffea` — `-22`, which
+  is `-EINVAL`. Something returned an error and the caller used it as a
+  pointer.
+
+**Ruled out: kernel stack depth.** This was the leading hypothesis and it is
+wrong. Raising `KSTACKSIZE` to 8192 with static per-slot stacks did not change
+the rate. The search was still worth it — the high-water mark really was 3736
+of 4096 bytes in netd, and the AP scheduler stack really was being handed a
+page it did not own — but neither was this.
+
+Not yet examined: TLB coherence when a page table is modified on one CPU while
+the process runs on another, `kalloc`'s free list under contention, and the
+buffer cache. `switchuvm()` and the `p->tf` handling were both read and look
+correct — `trap()` never overwrites `p->tf`, only `syscall()` does.
+
+Reproduce: boot `-smp 2` and count `trap 1` lines in the serial log. Six tty
+shells start at once at boot, which is when it almost always happens.
+
+Related: [[schunix-smp-and-memory-bugs]], [[schunix-console-tty]].