[Japabu]

Stage 3a of the backing-memory migration: the lifecycle calls, std and libc on top of them, and the hot paths the T14 measured. Stacked on #1003; lands with #1003 and #1010.

Commits

• e9805513f: the lifecycle calls.
  • SYS_MMAP and SYS_MUNMAP become vm_reserve and vm_release. They are joined by vm_protect, vm_discard and vm_decommit.
  • No VmProt member is both writable and executable. VmAt is Anywhere { align } or Fixed.
  • vm_protect commits reserved pages and changes protection in place. A committed page keeps its frame under None. An object range never gets more than the protection it was mapped with.
  • vm_discard frees a range's frames and keeps the range. vm_decommit frees both the frames and the commitment.
  • Every call is all or nothing over held pages, and every call counts against the range bound.
  • std's dlmalloc trims. std's thread stacks are the size asked for, above one guard page; the 2 MiB floor is gone.
  • libc's mprotect and madvise(MADV_DONTNEED) work.
  • ReadExec is NotSupported until ambient private RX lands.
• bf4deb3cd: review round 1.
  • No process can make the clock page writable. mmap_stress checks this, and the check turns red with the bound ignored.
  • libc's pthread stacks are reservations with a guard page, as std's are.
• f2e9370b1: on x86, a change reaches only the CPUs running the space (kernel::tlb_tags).
  • A CPU that ran the space before flushes on its next entry, if the space changed since.
  • The initiator flushes by page, up to 64 pages.
  • A change that no other CPU is running sends no IPI.
  • A loom model checks the pairing and turns red without its fence. This is a CI control.
• d9fa4bfd1: a Ring 3 page fault no longer seals the black box. It used to: each seal wrote back the whole 16 KiB box, 256 CLFLUSHes, on every first touch of every page. Such a fault is either served, or it ends its process through the crash path, which reports. A fault inside the handler is a Ring 0 fault, and that still seals.
• 34380bb26: a spawn copies each page of its program at the page's first touch, out of the image object (Kind::Copy). It no longer copies every segment byte when the process is made.
• 2d271c9f2: a spawn from /tmp does the same, out of a snapshot of the file (round 4 below).
• b4fac47ba: review round 4.
  • spawn_from_tmp overwrites its child's file in place, then cuts it and deletes it. A create-and-truncate write had replaced the file with a new one.
  • The reach count exists only in the test kernel, its one reader.
  • The black box's seal comment states one rule.
  • issues/a-swapped-binary-lives-where-any-process-can-rewrite-it.md: a /tmp spawn now runs a snapshot, so the service-lifetime window is closed.

The shootdown review's blockers

1. A CPU stops counting as running a space only after the CR3 write. tlb::switching(to, load) wraps the write: switch comes before it, and left after it.
2. No panic at 256 or more CPUs. Targets are read with get(me / 64). A CPU beyond the 256 that the targets hold falls back to a machine-wide shootdown.
3. tlb_shootdown_waits part 3 counts instead of timing. The test kernel's SPACE_REACHED (SYS_DEBUG 29) counts changes that reached another CPU. With no other thread running, a vm_release must leave the count unchanged. The 10 ms bound is gone.
   • The timed wait for a CPU running the space reds under the "reaches no runner" mutation (tlb_shootdown_waits.rs:162).
   • The count reds under the "reaches every CPU" mutation (:211).
4. The black box's SAFETY comment is corrected. Two CPUs that take a kernel fault or an exception at the same moment still write the one box. This is recorded in issues/two-cpus-faulting-at-once-write-one-black-box.md. The earlier per-fault write-back narrowing is replaced by d9fa4bfd1.

Why the last three: the T14 at 3446e9c33

osbench p50 on the same T14, against main (bench2/metal-r2b-t14-3) and Linux:

	head 3446e9c	main	Linux
mem.first_touch.4k ns/page	6,138	10 (eager 2 MiB)	927
mem.anon.total ns/MiB	1,580,629	50,312	258,177
mem.map_unmap_4k ns	2,465	76,079	1,635
mem.mprotect.4k ns	2,570	refused	1,026
proc.spawn_wait.tiny ns	48,737	715,422	51,285
proc.spawn_wait.large ns	6,560,963	715,981	53,698
thread.spawn_join.default ns	43,471	167,318	23,808
mem.realloc_grow.1m_256m ns	630 ms	29.7 ms	131 ns (mremap)

Round 4 below has the T14 result at the stack head.

Round 5: the T14 at 53049d55c, and review round 4

The T14 ran round 4's staged boots: 266 passed and 10 failed. Every red has a cause outside this stack:

• the three amdvi rows, which belong to the AMD bench;
• klogd_hosted, from the AMD row's deliberate DMA fault at 00:0d.0;
• i219_messages_on_its_msi_vector, which reports "the MAC saw 0 frame(s)" on the wire;
• main's five, below.

Passing rows include spawn_from_tmp, tlb_shootdown_waits, the global-leaf rows, pmm_accounting, the audio rows and the ACPI rows. Evidence: https://github.com/ToyOSOrg/evidence/tree/505932afaa9e65cee3e9e590e5206c7b867b4708/r5

osbench p50 on the T14, head 53049d55c against the base 35e930136, one run each:

	head	base
proc.spawn_wait.large	218 µs	817 µs
proc.spawn_wait.tiny	55 µs	759 µs
thread.spawn_join.default	30 µs	144 µs
mem.map_unmap_4k	2.7 µs	73 µs
mem.first_touch.4k	887 ns/page	11 (2 MiB pages; Linux 927)
mem.map_touch_unmap.4k	909 ns/page	207

The rows that are still slower are recorded with these numbers in issues/user-memory-hot-paths-are-slower-than-2-mib-pages.md. Landing waits on the owner's items 52 (refusable kernel objects) and 64 (accepting the recorded regressions).

Round 4: the T14 at dadeebe0a, and the rebase onto main 35e930136

The stack is rebased onto main 35e930136. One conflict, in libc's pthread.rs against #1011, was resolved by keeping the reserved stacks with #1011's Result returns. Evidence: https://github.com/ToyOSOrg/evidence/tree/e618281b0fd5528955d6a601b238efc3fde1e980/r4

osbench p50 on the T14, head dadeebe0a against its base 028244feb, one run each, with Linux on the same machine:

	head	base	Linux
mem.first_touch.4k ns/page	882 (6,138 at 3446e9c33)	11 (2 MiB pages)	927
proc.spawn_wait.large ns	6,412,352	735,469	53,698
proc.spawn_wait.tiny ns	52,954	736,615	51,285
mem.map_unmap_4k ns	2,726	83,176	1,635
mem.mprotect.4k ns	1,172	refused	1,026
thread.spawn_join.default ns	30,350	143,501	23,808
mem.anon.total ns/MiB	233,466	51,522	258,177
mem.realloc_grow.1m_256m ms	116	30	0.000131 (mremap)
work.build_shaped.j8 ms	326	573

• First touch. It is at Linux's cost. That the black-box write-back was most of the old cost is an inference: the builds compared differ in more than that change.
• The large spawn was still 8.7× the base. osbench's program is in the kernel's /tmp, and a program there was still copied whole at spawn. This is fixed in mm: the vm_* lifecycle calls, std and libc on them, and the hot paths the T14 measured (memory stage 3a) #1008's new 2d271c9f2: a spawn from /tmp copies each page at its first touch, out of a snapshot of the file that holds a reference to each of its pages. A write to a shared page writes a copy of it, so a later write, truncation or delete never reaches the child. The snapshot's reads take no lock, because a first touch copies under the space lock and read(2) holds the file cache's lock while it copies into user memory.
  • The new guest test spawn_from_tmp overwrites the file in place, cuts it to nothing and deletes it the moment its child is spawned, then has the child read 256 KiB of its data. With the source reading the file live, the child ends with a memory fault (control tmp-live-source).
  • On the T14 at 53049d55c: 218 µs against the base's 817 µs (round 5).
• Still slower than the base: mem.anon.total, realloc_grow (no mremap), and every row that copies through user memory, which is 15–40% slower: fs.tmp seq read and write, fs.served 4 KiB reads and writes, ipc.reqrep, pipe.throughput.65536. These are now recorded with numbers in issues/user-memory-hot-paths-are-slower-than-2-mib-pages.md.

The five unexplained T14 reds are main's. Each is red the same way under QEMU at the head and at its base 028244feb:

• test_rs_vector_state: 101, "a stat of /system/bin/test_rs_vector_state was refused".
• 209_libc_uname: uname answers -1.
• 210_stat_identity: the d_ino rows on /system answer NO.
• test_rs_handle_lifetime: 101. Its "undefined" flag bit is 32, which has been OpenFlags::EXCLUSIVE since main's d48ca18.
• test_rs_spawn_child_ends_first: 134.

Everything else on the T14 passed, apart from the AMD rows and klogd_hosted, as expected: tlb_shootdown_waits, pmm_accounting, osbench, the audio rows, counters and the ACPI rows.

libc_children's spawn_children_cap is red on main and green with the stack. Three runs each:

• On main 35e930136: 1, 1, 1. Child 240 ended by SIGSEGV twice, and the third run aborted.
• With the stack on 35e930136: 0, 0, 0.

main's SIGSEGV is a demand fault that finds no free 2 MiB page and is left unhandled (process.rs's PageAlloc::new(page_2m) returning None). With the stack, a fault draws a frame that was promised when the memory was committed (alloc_promised), so it cannot fail. A spawn past what memory holds is refused at the call instead. The stack removes that path rather than record it.

Checks

Round 4, at the stack head 53049d55c on main 35e930136: https://github.com/ToyOSOrg/evidence/tree/e618281b0fd5528955d6a601b238efc3fde1e980/r4. Round 3, at dadeebe0a on 028244feb: https://github.com/ToyOSOrg/evidence/tree/0966b10a03bba923c274e82daa560bbb57044a52/r3

• Host CI: exit 0.
• hosted_clang_hello: exit 0.
• 77 shared guest tests in one q35 boot, and 15 more QEMU rows and libc_children ×3: all passed.
• On the test kernel, exit 0 for:
  • tlb_shootdown_waits ×3;
  • abuse_kernel_addr;
  • global_leaf_discharge;
  • global_leaf_flush.
• The two shootdown controls ran with tlb.rs byte-identical to the head's. Each turns tlb_shootdown_waits red.
• global_leaf_user_flush is red under QEMU on the commit before the targeting too. Its metal row passed at 3446e9c33, and it is in the staged shared-debug boot.

The T14's DMA fault at 00:0d.0 is the AMD bench's deliberate test_rs_usbd_spare_fault (#1003's body has the trace).

Risks

• Costs remaining against Linux, recorded in issues/user-memory-hot-paths-are-slower-than-2-mib-pages.md:
  • the global frame lock on every fault;
  • two table walks per fault;
  • a bucket walk per cleared table of leaves;
  • a reached CPU flushes every user translation;
  • thread spawn at 1.8× Linux.
• There are no large user pages, and realloc has no mremap.
• No test proves that a switched-out CPU flushes on PCID hardware. That needs a thread pinned to a CPU, which no test can do yet (recorded).

🤖 Generated with Claude Code

https://claude.ai/code/session_01PXEk8BBMDT8tXu4AnENB9Q

[Japabu]

Review r1: #1008 at d4e282fe5 (memory stage 3a: vm_* lifecycle calls)

Reviewed: the top commit, its kernel, ABI, std, libc and test diff in full, plus kernel/src/mm/space.rs and kernel/pure/vm.rs at the head. Callers of AddressSpace::map were read for the new max (clock.rs, elf/mod.rs, inbox, ipc.rs, loader/tls.rs). Design reference: memory design rev 12 §2, §3, §6 and §8 stage 3.

Architecture. This matches the approved §2 table: vm_reserve, vm_protect, vm_discard, vm_decommit and vm_release. VmProt cannot express W+X. Every change to a present leaf shoots down, widening included. Discard and decommit free through the one clear_chunk, which revokes futex waits before the free. That satisfies stage 3's futex rule; rev 13 confirms the clear-primitive approach.

std's dlmalloc trims. std stacks are an exact reservation with one guard page, committed before start, and the 2 MiB floor is gone (Q15). The one-page guard is justified: stack_probes = Inline on both ToyOS targets in the rust fork. The copied KNOWN masks go, and the ABI owns VmProt::from_u64. No fork consumes the removed mmap, munmap or MmapProt: I searched the rust pin's library/ and the cargo git checkouts and found none.

Net change: +783/−530. About 200 lines of that is mmap_stress, rewritten as the stage's guest test (1 TiB reservation, partial release, fixed replacement, each unreachable kind faulting in a child). space.rs adds about 90 lines.

ReadExec → NotSupported: nothing breaks today. main never had executable anonymous memory. MmapProt had no exec bit, sys_mmap documented "never executable", and libc answered PROT_EXEC with ENOTSUP. std_tls_cranelift compiles but never executes generated code. memmap_exec_refused expects the refusal. Nothing in-tree, nor in the forks I searched, maps code. Q13's ambient RX belongs to stage 4 together with UCI/UCT (§8), so deferring it is within the approved order and is not a lost capability.

max per object range. This is narrower than §2's "handle rights bound max_prot": here max is the protection the range was mapped with. mem_map with rights does not exist yet, so I accept it for this stage. It is also what protects the shared objects. The clock page is one SharedMemObject mapped Read into every process (clock.rs:72-91), and vm_protect's within(max) check (space.rs:283-289) is the only thing that stops one process making it writable for all.

Findings

• BLOCKER kernel/src/mm/space.rs:383-389: clear_chunk's contract says "The inventory no longer holds the range." discard and decommit now call it while the inventory still holds the range; unlinking is correct only because backed() keeps discard's tables. The comment is false at this head. mm: a commitment is promised its frames when it is made (memory stage 3b, strict commit) #1010 already rewrites it ("no range the inventory still backs needs"), so move that wording into this commit. Otherwise main carries the false contract until mm: a commitment is promised its frames when it is made (memory stage 3b, strict commit) #1010 lands, which is gated on an owner decision.
• BLOCKER kernel/src/mm/space.rs:283-289, tests/guest/rust-tests/src/bin/mmap_stress.rs: the new cross-process boundary has no test and no negative control. If the max check regressed, any process could make the global clock page writable for every process, and nothing would turn red. Prot::within has a host test, but its application in protect does not. Cheapest sufficient check, needing no new boot: in mmap_stress, assert that vm_protect(CLOCK_PAGE, PAGE, ReadWrite) is PermissionDenied and the page stays readable. Then record a control with the check removed that turns it red.
• BLOCKER sdk/libc/src/pthread.rs:137: libc's pthread stacks still come from the heap, with no guard page. The design (§3, Q15) puts a Reserved guard below each thread's stack, and stage 3 is where "libc and std switch over". The PR lists the gap under Risks, but no issue records it. That is silent debt: a C thread that overflows its stack writes into the heap without faulting. The fix is the same shape as std's thread.rs change (vm_reserve(size + GUARD, None), then vm_protect of the stack, then vm_release at reap), so do it here. Failing that, record it in issues/ with an exit.
• BLOCKER (evidence) tests/corpus/tinycc/206_libc_refusals.expect: four changed expectations (mprotect executable, mprotect off a page, madvise DONTNEED, page after madvise: zeros) run only in the shared metal boot, and that boot has not run. mm: a commitment is promised its frames when it is made (memory stage 3b, strict commit) #1010's evidence shows it staged, metal-staging/, exit 2 = not run. memreq's host tests cover classification, but not the kernel answers behind EINVAL and the zeroed page. The pending metal readback (boot:testcases) must show this case green before landing.
• SUGGESTION kernel/src/syscall/vm.rs:26 (private_prot): this function also validates vm_protect on object ranges, so the name says more than it does; vm_prot would fit. Optional.
• NOTE (orchestrator, landing order): at this head allocator_stress is red, because try_reserve(16 GB) succeeds without a charge (from mm: one inventory per space, lazy 4 KiB pages, and memory objects (memory stage 2) #1003). If mm: the vm_* lifecycle calls, std and libc on them, and the hot paths the T14 measured (memory stage 3a) #1008 lands while mm: a commitment is promised its frames when it is made (memory stage 3b, strict commit) #1010 waits on the kernel-object decision, main's guest suite carries that known red. Stages 1–3 being one migration permits that, but the red should be recorded, or mm: one inventory per space, lazy 4 KiB pages, and memory objects (memory stage 2) #1003 to mm: a commitment is promised its frames when it is made (memory stage 3b, strict commit) #1010 should land together.
• NOTE (evidence revisions): this PR's own runs are at cd246a7e2 (guest) and d851d99e8 (host), before the rebase that renumbered SYS_VM_* (135 → 136) and brought osbench round 2. The stack head 3446e9c33 (pr-1010 evidence: host 0, 76 shared tests plus 15 rows) contains this commit, and that is adequate for the code. The merge queue's host run covers the head itself.

SEND BACK

[Japabu]

Review round 1 answered: the clear contract was rewritten with #1003's fix; the clock page's PermissionDenied is tested and its control reds; libc pthread stacks have a guard page; 206_libc_refusals is green on the T14. Per the coordinator's classification, the x86 all-CPU shootdown is fixed before landing (36e0bab, targeted, loom-modelled, both halves controlled), and the T14's measurements added two hot-path fixes: the black box's per-fault write-back and lazy segment copies at spawn. Evidence: https://github.com/ToyOSOrg/evidence/tree/dced920e2be8b42b56c8c2b54daa83ab9a36b8d3/r2.

[Japabu]

Review r2: #1008 at 0c066deeb, against r1's items

Scope: r1's four blockers. a71579879 (targeted x86 shootdown) has its own reviewer; I note only how it interacts with these items.

r1 items

1. clear_chunk's false contract: resolved. The clear was rewritten in mm: one inventory per space, lazy 4 KiB pages, and memory objects (memory stage 2) #1003's round 1 (c7d963db0). At this head clear's doc (kernel/src/mm/space.rs:415-424) says "every table over them no range the inventory still backs needs", which is true for release, discard and decommit alike.
2. Clock-page bound: resolved.
   • mmap_stress asserts that vm_protect(CLOCK_PAGE, PAGE, ReadWrite) is PermissionDenied. It runs in an existing boot.
   • The control protect-ignores-max (pr-1008 r2 dced920e2) turns it red with "the clock page made writable".
   • lcr1-guest1.log shows the set green.
3. libc pthread stack guard: resolved (023b82866).
   • reserve_stack reserves size + GUARD as None, commits the stack with vm_protect(ReadWrite), and releases the whole reservation on a refused commit, a refused spawn and at reap.
   • thread_spawn gets the reservation's top and the stack's base.
   • The heap no longer holds stacks.
   • The GUARD comment honestly says a C frame larger than a page can skip it, as on any POSIX system.
4. BLOCKER (evidence, still open) tests/corpus/tinycc/206_libc_refusals.expect: 206 is not shown green on the T14.
   • The T14 readback at 3446e9c33 is in metal-3446/testcases/kernel.log.
   • The judge refuses the whole testcases boot: ch-metal-judge.log:230, "FAIL 206_libc_refusals: testcases's own log is missing its parts 2 to 38; no row is judged on it".
   • The retained log does not contain the case's output either. grep finds neither mprotect executable nor page after madvise.
   • The counters_metal log-volume decision blocks this.
   • Cheapest unblock: if one of the three options is not taken soon, run 206 in a boot whose log survives (shared-debug, or a corpus-only readback).
   • The libc behaviour changed after that run (pthread stacks), so the run should be at this head or later.

Interaction with the targeted shootdown

None that affects these items. The pinned-frame keep in #1010's discard depends on the space lock, not on which CPUs are shot down, and a copy reaches its pinned frame through the direct map, never through the user leaf. Clock-page protection changes nothing that is present, so it sends no IPI.

Minor

• SUGGESTION tests/guest/rust-tests/src/bin/mmap_stress.rs (the new clock block): let _ = toyos_abi::clock::page(); reads as dead code. It actually checks that the page is still readable and still carries the clock (page() asserts the magic). A binding plus an assert!, or a three-word comment, would say so.

SEND BACK: only the 206 metal evidence remains. The code items are resolved.

[Japabu]

Review of #1008: targeted x86 shootdown, black-box write-back, lazy segment copies

Scope: three of #1008's commits at 0c066deeb, which the coordinator named. They are a71579879 (x86: a change to a user space's leaves reaches only the CPUs running it), 51ead882c (black box: a page fault writes back only the record it sealed) and 0c066deeb (lazy segment copies).

I read:

• kernel/src/tlb_tags.rs in full, with x86_64/tlb.rs (user_change, switching, flush, serve_ipi, poll) and paging.rs (Cr3::activate, flush_user_page, UserTables::shoot_down);
• every CR3 load in kernel/src (hw.rs context switch, activate_kernel, load_kernel_flush, sched/driver.rs);
• the loom model and its CI control, tlb_shootdown_waits, and the shootdown track issue;
• blackbox.rs and toyos_blackbox::seal, and the exception entry that calls it;
• Kind::Copy in kernel::vm, space.rs (private, copy, page_leaf, copy_in), loader/mod.rs and file_backing.rs;
• evidence dced920e2 r2: README, loom log and control, the reach-no-runner and reach-every-cpu controls with their patches, the ts- and lz- guest logs, and protect-ignores-max.

The evidence's 1877d8b4d maps to 0c066deeb by the PR body's table. I ran nothing.

Targeted shootdown

Architectural assessment

The design is sound and the right size.

• What is tracked. For each PCID: the CPUs running it, and the stamp of its last change. For each CPU: the stamp its last full user flush covers.
• Change side. A change stamps the tag with release ordering, fences, reads who is running it, and reaches only those CPUs.
• Entry side. A CPU sets its running bit, fences, and reads the tag's stamp with acquire ordering. If the tag changed since the CPU's last full flush, it flushes every user translation before it loads the tag's root.

That is the Dekker pairing the loom model checks, and the control (tlb-tags-enter-relaxed) turns it red.

I checked these points, and each holds:

• A reached CPU that has already left the space still does a full non-global flush on every PCID (answer → flush(Narrow) → INVPCID type 3 or a CR3 reload). It records flushed only from a stamp read before that flush, so its coverage is never overstated.
• An unrelated full flush that covers a change's stamp. The CPU is not running the tag at that moment, so it cannot re-cache the tag's entries before it next enters. On entry it reads changed with acquire ordering, so the walk sees the change's leaves.
• The initiator. Its local INVPCID by address uses the tag only when the CPU is in the tag's running set. When it is not, as with an aperture revocation or a kernel-mapping release from another process's context, its stale entries wait for its next entry. Unlinked tables widen the range to the whole space, so paging-structure caches are covered.
• PCID reuse. It still goes through the reclaim shootdown to every CPU, which also advances flushed everywhere.
• Without PCIDE (TCG). The tag is still the pool's value, read from Cr3, so the running sets stay correct, and each CR3 write also flushes.
• AArch64 is untouched, which is right, since its TLBI operations broadcast in hardware.

Findings

BLOCKER 1. A CPU leaves the running set before it stops using the space's tables. Tags::switch sets the bit for to, then clears the bit for from. Cr3::activate calls it before write_cr3 (paging.rs:386-391).

• Between the clear and the CR3 write, this CPU still has from's root and PCID loaded.
• A concurrent change to from in that window does not reach it. That change frees the leaf frames after its shootdown, and mm: one inventory per space, lazy 4 KiB pages, and memory objects (memory stage 2) #1003's clear also frees the unlinked tables.
• The SDM lets a processor create TLB and paging-structure-cache entries for the current PCID speculatively, for accesses that never occur (Vol. 3A §4.10.2.3). Such a walk can read a freed table frame that is already reused, and it is not established that it cannot also write an accessed flag there (§4.8).
• The window is a few instructions with interrupts off, and the result is only rarely observable. But the protocol's correctness argument should not rest on it. leave's contract ("it touches none of its memory from here") covers software, not the walker.

Fix, which costs nothing: clear from's bit after the CR3 write, while keeping enter(to) before it. The CPU is then briefly in both sets, which is conservative. State in tlb_tags that "running" lasts from before the root is loaded until after it is replaced.

BLOCKER 2. user_change panics on a CPU numbered 256 or above. targets[me / 64] (tlb.rs, user_change) indexes a 4-word array directly. The beyond fallback, which handles more than 256 CPUs, applies only to targets reported through the closure. Nothing caps the CPU count (smp::cpu_count), so on a machine with more than 256 CPUs, every user change initiated from a high-numbered CPU panics the kernel. Fix: use targets.get_mut(me / 64), and when the index is out of range, take the machine-wide path.

BLOCKER 3. tlb_shootdown_waits stage 3 bounds a QEMU timing from above. "A munmap no other CPU's thread could reach took {elapsed}ns" asserts elapsed < FLOOR_NANOS (10 ms) on the test kernel under QEMU. Host load alone can push one munmap past 10 ms, and root's testing rules use QEMU's clock only as a hang ceiling. Stages 1 and 2 are lower bounds against an injected 20 ms delay, which load cannot falsify; stage 3 is not.

Fix: make the claim a count. For example, compare the issuer census (ISSUED[Unmap]) or the receivers' tlb interrupt column before and after the lone munmap, and assert that no IPI was sent and none was waited for. The reach-every-cpu mutation then still turns it red, by count. Also record in the test's registration where it runs (q35 test kernel through SWEEP_PARAMS).

Owed and recorded, not blocking. The PCID property itself has no automated test, because TCG has no PCID. That property is that a switched-out CPU keeps entries that the flush on entry must remove. The track issue records the metal case and its exit, which waits on pinned threads. The loom model is the proof of the protocol. The INVPCID type 3 semantics are the SDM's. Run tlb_shootdown_waits and its stage 3 count in the requested T14 run, since the T14 has PCID.

Suggestions

• Per-space flush on entry. The flush on entry is INVPCID type 3, which drops every space's non-global entries on that CPU. Each thread migration into a space that changes often (V8's toggles, allocator trimming) therefore costs every other space on that CPU its TLB. A stamp per (CPU, tag) with an INVPCID single-context flush of to would keep those entries. The memory cost is about 32 KiB per CPU for 4,096 tags.
• By-page flushes on reached CPUs. A reached CPU flushes everything. If the CPU still runs the tag when it answers, by-page INVPCID for up to 64 pages would preserve its TLB, as the initiator already does for itself.
• Loom coverage. The model covers only entry against change. Add a case in which the running CPU leaves while the change is made, and one in which a third CPU's unrelated flush sets flushed, so both remaining arguments above are model-checked too.

Black-box write-back on faults

The narrowing is correct. seal returns the payload length, HEADER is added to it, and the record is written before it is written back. Every other seal still writes back the whole box.

BLOCKER 4. The SAFETY comment is false on the path this change speeds up. with_page_written says "the panic path holds PAINTING and the quiesce path has stopped every other CPU, so the one CPU still running is the only writer". record_fault runs at every exception entry on every CPU (idt/mod.rs:341), so concurrent page faults on two CPUs each form a &mut [u8; BYTES] over the same page and write it at once. That is aliasing and a data race, and a torn record can carry a valid checksum. This predates the change, but the change makes the 4 KiB first touch its hottest caller, and every fault on every CPU now bounces and flushes the same header lines.

Fix: either skip the seal for user-mode page faults, as the cheapest option. Such a fault is served or ends its process, and a fault inside its handler is a kernel-mode fault that seals itself. Or give each CPU a record slot. At minimum, correct the comment and record the race and the cross-CPU line traffic in user-memory-hot-paths-are-unmeasured-against-2-mib-pages.md.

The gain is inferred from the 256 lines and is not measured. It belongs in the stack-head re-measurement.

Lazy segment copies

The change is correct, and it restores main's spawn shape (pages at first touch) without bringing back the deleted /tmp defect.

• Only SharedImage answers object(). A tmpfs or ROOT backing is still copied whole.
• An image object's bytes are the spawner's own, as SharedImage's contract already says. Boot images are read-only.
• Kind::Copy is committed and owned. Its tail and continued_by carry offset and len correctly, and a host test covers a cut and a re-join.
• copy_in bounds the copy by len, by the page and by the source's size.
• The source Arc keeps the object alive for the range's life, as main's file-backed regions did.
• vm_discard re-copies a page from the source, as documented.

A suggestion: the source object now stays alive and charged to the spawner for as long as any child runs a range of it, while the child is also promised the range in full (#1010). Two commitments then exist for the same image while a child lives, until shared text (stage 4 and the /apps stage) removes one. Note that in the hot-path record or in the stage-4 record.

Verdict

The design and the two performance fixes are right. Fix the leave ordering, the CPU-index panic, the QEMU upper bound in the test, and the black box's single-writer claim.

SEND BACK

[Japabu]

Response to the shootdown review (SEND BACK, four blockers), at 78e83ba1b (da71e45fc and 4ff6d91e4):

1. Leaving. A CPU stops counting as running a space only after the CR3 write. tlb::switching(to, load) calls switch before the write and left after it.
2. 256 CPUs and up. targets.get(me / 64): a CPU beyond the 256 that the targets hold falls back to a machine-wide shootdown, with no panic.
3. Stage 3 counts. The 10 ms bound is gone. The test kernel's SPACE_REACHED (SYS_DEBUG 29) counts the changes that reached another CPU, and a lone vm_release must leave it unchanged. The "reaches every CPU" mutation turns the count red at :211; the "reaches no runner" mutation turns the timed wait red at :162 (r3/controls/).
4. Black box. The SAFETY comment is corrected, and the race is recorded in issues/two-cpus-faulting-at-once-write-one-black-box.md. A Ring 3 page fault no longer seals at all, which replaces the per-fault write-back narrowing.

Evidence: https://github.com/ToyOSOrg/evidence/tree/0966b10a03bba923c274e82daa560bbb57044a52/r3. tlb_shootdown_waits is in the staged T14 shared-debug boot.

[Japabu]

Review r4: #1008 at 2d271c9f2, on main 35e930136

Scope:

• the four shootdown blockers (in f2e9370b1 and d9fa4bfd1);
• the new commit 2d271c9f2, the /tmp snapshot spawn;
• the pthread.rs rebase against libc: a child's end, an alarm and a quit reach a handler #1011;
• the r4 evidence and the T14 r4 readback.

I ran nothing.

Architectural assessment

2d271c9f2 is the right shape:

• Every FileBacking now answers a CopySource, either the image object or an immutable file_cache::Snapshot. The whole-copy path in load_segments is deleted.
• Each file-cache page becomes an Arc, so a snapshot costs one reference per page. A write is copy-on-write through Arc::make_mut.

That removes the large-spawn regression without bringing back the old defect (a running program reading a file that someone can rewrite). It needs no new locking.

Kind<O, S = O> in the pure vm is the minimal way to let the kernel name a trait object that the pure crate cannot name.

The four shootdown blockers: all resolved

1. Leave order. tlb::switching calls Tags::switch, which enters to before the load and answers from, and calls left(from) only after load() (tlb.rs, paging.rs:386-400). The switch doc states the "from before the load until after it is replaced" contract.
   • Every user CR3 load goes through Cr3::activate: the hw.rs context switch, enter_idle_loop, and the kernel root.
   • The remaining raw write_cr3 calls are a same-root reload, the pre-PCID boot load, and the AP trampoline.
2. CPU index.
   • targets.get(me / 64) falls back to the machine-wide shootdown.
   • The beyond flag covers runners past 256.
3. QEMU bound.
   • Stage 3 now compares SPACE_REACHED before and after one vm_release.
   • The reach-every-cpu-r3 control reds at :211 ("interrupted another CPU 2 time(s)").
   • reach-no-runner-r3 reds at :162.
   • The module doc says where the test runs.
4. Black box. A Ring 3 page fault no longer seals. The SAFETY comment now states the race, and issues/two-cpus-faulting-at-once-write-one-black-box.md records it with an exit.

2d271c9f2: correctness

• Copy-on-write is enforced by the type. Arc<Box<[u8; 4096]>> has no DerefMut, so every write must go through make_mut or get_mut. That rules out an in-place write to a shared page at compile time. There are two writers, apply_write and the straddled-tail zeroing in set_size_locked, and both use make_mut.
• Concurrency with the snapshot. A snapshot is dropped outside FILE_CACHE, under a space lock, while a writer calls make_mut under FILE_CACHE. Arc's unique check (acquire) pairs with the release in the snapshot's drop, so there is no race.
• Truncation and delete only remove map entries. The snapshot keeps its own references.
• Reads take no lock. Snapshot::read reads immutable data only.
• Lock order. The snapshot is taken at the same point as the existing header read, before the child's space is locked and with no space or process lock held. The order FILE_CACHE then space (a user copy under read_page/write_page) is unchanged, and CopySource::read under the space lock takes nothing. The comment at the call site is accurate.
• Bounds.
  • copy_in clamps n to size - offset, so Snapshot::read's assert cannot be reached from user input.
  • copied is clamped to the snapshot's size.
  • If the file changes between the header parse and the snapshot, only the spawner's own child is affected.
• The backing.is_none() assert holds. Only TmpFs implements open_backing, and its open_file returns None, so no tmpfs file is given a backing.
• Memory. A write to a shared page allocates a copy under FILE_CACHE, from the same infallible heap as every tmpfs page. That growth is not new; it falls under nothing-charges-kernel-memory-to-a-process.md. The hot-paths issue records that the snapshot holds memory twice.

Findings

• BLOCKER tests/guest/rust-tests/src/bin/spawn_from_tmp.rs:1-4, 574: the test does not overwrite the file it spawned, although its doc, the commit message and the PR body say it does.

  • std::fs::write opens with create+truncate.

  • ops::open serves truncate+create by vfs.delete_file followed by vfs.create_file (kernel/src/object/ops.rs:136-144).

  • The snapshotted file's ref_count is 0 by then, so mark_deleted drops it at once. The "overwrite with hlt" writes a new FileId, and the later remove_file deletes that new file.

  • The test therefore establishes only that the child survives the deletion of its file. That is the claim the tmp-live-source control actually reds on: the live reads find no file and return zeros, and the child faults in its text.

  • Copy-on-write itself is established by the type, as above, so it does not need this test. But the test's description must be true.

  • Cheapest fix, at no boot cost: overwrite in place, which also covers both make_mut paths:

    1. OpenOptions::new().write(true).open(COPY)?.write_all(...);
    2. set_len(…) to truncate;
    3. remove_file.

    Otherwise, describe the test as "replaced and deleted".

  • 0xF4 is called hlt, an x86 name, in a shared test that also runs on AArch64. Call it "bytes other than its own".

• BLOCKER issues/a-swapped-binary-lives-where-any-process-can-rewrite-it.md:21-22, 40-41 is false at the head. The issue says "The kernel pages a binary in on demand" and "the kernel still pages the running binary in from the file".
  • A program spawned from /tmp now runs a snapshot taken at the spawn, so the issue's second window ("for the service's life") is closed.
  • The stack deleted a-program-run-from-tmp-pages-in-code-any-process-can-rewrite.md for the same reason, but left this record unchanged.
  • Fix: update the record. Only the window between the hash and the spawn syscall remains, and its exit still applies.
• BLOCKER kernel/src/mm/space.rs Usage::reached (with AddressSpace::shoot_down): the field and its fetch_add ship in the production kernel, but the only reader is the #[cfg(feature = "test-actuators")] accessor behind SPACE_REACHED. Root forbids production machinery that exists solely to satisfy a test. Either:
  • gate the field and its increment on test-actuators; or
  • make it a real per-process statistic next to faults/fault_ns, as "changes that interrupted another CPU", which is a useful number.
• BLOCKER kernel/src/arch/x86_64/idt/mod.rs:334-346: the comment contradicts itself. It says "Every vector, the page fault included: a diagnostic that skips the commonest fault class is one that misses the answer", and then appends "But not a Ring 3 page fault". Replace both with one short paragraph, rather than leaving the rule and its exception side by side: seal before every handler except a Ring 3 page fault, which is served or ends its process through the crash path, while a fault inside its handler is Ring 0 and seals.
• SUGGESTION kernel/src/loader/mod.rs spawn: take the source first, then read the ELF header (read_file_range) and the TLS template (elf::read_backing_into) from it. One spawn then reads one version of the file, and the commit's claim that the child "runs the bytes it was spawned from" becomes exact, not true only from the snapshot onward.
• SUGGESTION file_cache::snapshot: snapshot only the pages that the PT_LOAD file ranges cover. The layout is already known at that point. This shortens the walk under the global FILE_CACHE lock, and the snapshot no longer holds a file's tail that no segment maps.

pthread.rs rebase against #1011: correct

• bf4deb3cd keeps libc: a child's end, an alarm and a quit reach a handler #1011's create(…, counted) -> Result split, spawn_own, counted in Thread, and thread_started/thread_ended.
• It replaces only the heap stack with reserve_stack, and releases the reservation at reap and on a refused spawn.
• The diff against 35e930136 contains nothing else.

Evidence

• Head checks (53049d55c, r4 README).

  • --ci host: exit 0, 102 steps.
  • The q35 sweep: exit 0, with spawn_from_tmp passing (h9-guest.log:930-932).
  • The test kernel: tlb_shootdown_waits ×3, exit 0.
  • hosted_clang_hello: exit 0.

• Control. tmp-live-source reds the sweep (test-exit=1).

• T14 r4 (metal-r4/judge-h.log).

  • spawn_from_tmp: the parent and the /tmp child both exit 0.
  • tlb_shootdown_waits, the three global-leaf rows, pmm_accounting, the four audio rows and the ACPI rows: PASS.

• osbench proc.spawn_wait.large p50.

  	p50
  head	217,579 ns
  base 35e930136	816,571 ns
  dadeebe0a	6.41 ms

  The regression is gone; the head is now 3.8× faster than the base. One run each.

• Other T14 rows. proc.spawn_wait.tiny is 54.6 µs against 759 µs, and thread.spawn_join 30.5 µs against 190 µs.

• For the orchestrator. The PR body still says "Metal is staged, not run" and still quotes dadeebe0a's 6.4 ms. Its "confirms the inferred cause" for first touch compares builds that differ in more than the black-box change, so it is an inference, not a confirmation.

SEND BACK: the four blockers above. All of them are small.

[Japabu]

Review r4, in b4fac47ba:

1. spawn_from_tmp: the test now writes its child's file in place with OpenOptions::write, cuts it with set_len(0) and then removes it. The "hlt" wording is gone. It passed ×3. Under the live-read control it turns red: the child ends with a memory fault (r5/controls/tmp-live-source-r4.*).
2. The swapped-binary record: the service-lifetime window is now marked closed by the snapshot. Only the window between the hash and the spawn is left.
3. Usage::reached: the field and its increment exist only under test-actuators. tlb_shootdown_waits ×3 passed on the test kernel, and --ci host (both architectures' clippy) passed.
4. idt/mod.rs: the comment is now one paragraph stating one rule.

I did not take the two suggestions: reading the header and TLS from the snapshot, and a segment-only snapshot.

Evidence: https://github.com/ToyOSOrg/evidence/tree/505932afaa9e65cee3e9e590e5206c7b867b4708/r5

[Japabu]

Review r5: #1008 at b4fac47ba

Scope. My four r4 blockers and the one new commit, b4fac47ba. git range-diff shows every earlier commit unchanged. I read the r5 evidence (pr-1008 r5 505932afa, local ev5/). I ran nothing.

r4 blockers: all resolved

1. spawn_from_tmp writes the spawned file itself. The test now opens the file with OpenOptions::new().write(true), without truncate.
   • That open takes ops::open's open_target path, so the write goes to the same FileId. It exercises apply_write's make_mut on pages the snapshot shares.
   • set_len(0) reaches ftruncate → set_size, which drops the pages.
   • remove_file then deletes the file.
   • The module doc now matches what the test does, and it no longer calls the bytes hlt.
   • Evidence:
     • h10-guest.log: spawn_from_tmp ×3, exit 0 at 5bb1b9dd1.
     • controls/tmp-live-source-r4.log: the live-read control is red (test-exit=1). The child dies, so the parent's write to its stdin fails at spawn_from_tmp.rs:43.
2. The swapped-binary record is accurate. issues/a-swapped-binary-lives-where-any-process-can-rewrite-it.md now records the second window as closed by file_cache::Snapshot. It adds that a restore re-enters the first window, and that only the first window and its exit remain.
3. Usage::reached is gated. The field and its increment are both under #[cfg(feature = "test-actuators")]. The shipping kernel keeps only let _reached from tables.shoot_down, which costs nothing. h10-testkernel.log shows tlb_shootdown_waits ×3, exit 0, with the gated count. h10-host.log (--ci host, 102 steps, exit 0) covers both configurations through clippy.
4. The idt comment is one rule. It is a single three-line paragraph: every vector seals except a Ring 3 page fault, with the reason.

Declined suggestions

The implementer declined my two optional suggestions: reading the header and TLS template from the snapshot, and taking a snapshot of only the segment pages. Both were optional, and I do not reopen them.

Evidence reuse

Round 5 changes only:

• one test;
• a field that exists only in the test kernel;
• a comment;
• issue records.

So the T14 r4 results at 53049d55c still hold. That run had 266 passed, and its 10 reds are all accounted for outside the stack: #1033 fixes main's five, and #1027 records the machine-selection defect. Large spawn was 218 µs against the base's 817 µs.

LAND. It lands jointly with #1003 and #1010, after owner items 52 and 64.

[Japabu]

Landing as part of the memory stack (#1003, already merged; then #1008 → #1010 → #1045), rebased onto 4dc75f5 with #1003's duplicated commits dropped and no conflicts. Each PR was reviewed LAND. #1045 passed review r2 and its T14 run at 1595bbb (273 passed; the 5 failures are known and unrelated), and its QEMU checks at fb0f316 and b3f98b4 passed. Host CI is green at 37b63fc. Owner items 52, 64 and 71 cover this stack. Machine-level accounting lands first; per-job accounting, the system-controls floor and the supervisor restart retry are recorded as next.