A shared region's last handle takes its list of mappings, and a map that finds none is refused

[Japabu]

The defect

SYS_SHM_MAP resolves its handle and clones the object's Arc under the process-data lock (sys_shm_map, kernel/src/syscall/ipc.rs), drops the lock, and calls SharedMemObject::map_into (kernel/src/object/shm.rs). A sibling thread that closes the region's last handle in between retires the object: the zero-handle hook empties the list of mappings, once. map_into checked nothing, installed a writable mapping and appended it to a list nothing reads again. The last Arc's drop then trips SharedMemObject::drop's debug_assert!.

Each step of the audit's trace holds on main at 0174516. Two corrections to the record: the object lives in kernel/src/object/shm.rs; and the kernel has one build profile, toyos, with debug-assertions = true (kernel/Cargo.toml), so on every kernel this tree builds the outcome is the panic — a userland race that panics the kernel — and the freed-while-mapped pages are what the assert stands in front of.

The fix, per decision

• Who owns what. The handle count owns the mappings; the Arc count owns the pages. That was already the design: a syscall's Arc can be stranded on a killed thread's stack, so the mappings cannot ride it. But its first half was a convention: the list was a Lock<Vec>, and an emptied Vec accepts a push.
• The structure. The list is now object::Held<Vec<..>>, which every other deferred object already keeps its released resource in. The hook takes the list out, so after it there is no list; map_into reaches the list only through Held::with_mut, under the lock the take used. One lock, no check-then-act: a map lands before the take and is torn down by it, or finds nothing and answers Gone having touched no page table. Held gains take and with_mut; release is now drop(take()).
• The answer. Gone, as a partition claim whose last handle went answers a transfer (DeviceClaim::partition_view). toyos-abi's shm_map doc says so; a doc comment, no identity change.
• A region no handle ever named (an inbox's ring page, mapped by inbox::create and unmapped by InboxRef's drop) never retires and keeps its list: unchanged.
• Drop's assert stays, as the check that a handle-less owner unmapped before letting go.

The same shape elsewhere

Read: every deferred row of kobject! and every syscall that acts through a reference cloned out of the table.

• Pipes, connections, inboxes, device claims: the resource is in Held, reached under its lock. Holds.
• Ports: closed and pending share one lock (PortQueue); Connector::push checks and inserts under it. Holds.
• A region lent to a device (pcidev::dma_map) or read as a program image (file_backing::SharedImage) after its last handle went: both hold the Arc, which owns the pages, and neither makes a user mapping. Holds.
• Does not hold, PCI: a device call resolves its claim to a slot index, drops the lock, and pcidev::with_bound(slot) acts on whoever is bound there by then. That is issues/a-pci-call-in-flight-names-its-function-by-a-slot-the-next-claim-reuses.md, which main has from Three audit claims traced: a BAR asked for twice panics the kernel, netstack keeps a dead client's socket, and a PCI call's slot is not its claim #755; this branch files nothing on it and does not fix it.
• ISA and ACPI rows, traced. The calls on the claim do not have the window: a read and a write (read_device, write_device, kernel/src/object/ops.rs) run whole under the process-data lock of the table holding the claim's one handle (sys_read, sys_read_nonblock, with_object_ref), and a claim carries no Rights::DUP, so the step that fails is "lets the lock go": nothing can release the claim inside a call, and after the close the handle refuses it. The acpi claim's mediated access and the Global Lock, and acpiserver loading the machine's tables through them #749's reviews reached the same answer from the binding's side (claim_row mints nothing while a process is bound, and process_ends runs after the last thread left). A poll does have it, and it is issues/a-poll-registered-racing-its-own-close-outlives-the-release.md, which main already carries with an exit written for every claim's watch; this branch files nothing on it and does not edit that file. What the trace adds to it: inbox::resolve clones the claim out and arm then reads isa::has_irq(row) and registers on isa::watch(row), neither of which asks whose the row is, and the ISA and ACPI rows have the window only where the binder moved the handle on and ended (isa::process_ends takes the binding back while the claim stays minted in the receiver's table, so after the receiver's close claim_row mints the row again). Where the poller is the process that bound the row, claim_row answers Owned until its last thread has left. Read from the code, not run.
• A process that ends with a region mapped (the review's off-fence note): holds. Nothing but an inbox's teardown calls unmap_from, and teardown_resources touches no region's list, so the entry's PageTables Arc keeps the dead process's address space, its page-table pages and its user PCID, until the region's last handle goes anywhere; one entry per such process, unbounded, against a pool of MAX_USER_PCID tags whose exhaustion refuses every spawn. Pids are never reissued, so no later process is answered a dead one's address. Filed as issues/a-region-keeps-the-address-space-of-every-process-that-ended-with-it-mapped.md. Read from the code, not run; not fixed here.

For wt/toyos-barremap (#761): a BAR window is its own SharedMemObject and goes with that object's last handle, not with the claim's (sys_device_bar_map, kernel/src/syscall/device.rs). After this change a retired region has no mapping list and can never be mapped again, so a retired object must never be handed out a second time. This branch does not touch that path.

Checks (high-risk: memory management, concurrency)

The race itself is covered by the type, and no test is added for it. The window is closed by where the list lives, which a reader checks in map_into's last line and the hook's first. The loom models and the process-life simulator compile no object-layer file, and the kernel has no actuator that holds sys_shm_map between its clone and its map; none is added.

Negative control, executed. The bad interleaving needs no concurrency to state: it is clone, last handle dropped, zero-handle queue drained, map_into. A probe patch (posted below as a comment, never landed) runs exactly that at boot against the real object, allocator and a fresh user address space. Both arms on 8340830, cargo test --test toyos-build -- --nocapture machine_shutdown_short_stop, the tree restored and git status --porcelain empty after each:

arm	exit	the kernel's words
the fix's kernel/ diff reverted + probe	1	shm-probe: a map after the last handle's teardown answered Ok(ffff400000) then PANIC: panicked at src/object/shm.rs:186:9: shm koid 4 freed with a live mapping
the fix + probe	0	shm-probe: a map after the last handle's teardown answered Err(Gone) then shm-probe: the region was freed and the kernel is running

This is the first execution of the defect. Independent oracle: none exists beyond the kernel's own pre-existing assert, which the fix did not write and which is what fires in the red arm.

Gates

The head is 933d291; every gate in this table was measured at 8340830. Since then the branch dropped the duplicate issue from its fix commit (now 73fd889, the same source tree), merged origin/main at 2e781a4, and filed, narrowed and deleted issue files. git diff 83408305e 933d291e7 -- . ':(exclude)issues' and git diff 58b768a03 933d291e7 -- . ':(exclude)issues' both print nothing, exit 0: every byte outside issues/ is what was measured here and what the T14 booted, and the merge moved no code, so nothing in this table was run again. At 933d291, cargo test --test toyos-checks: exit 0, test result: ok. 36 passed; 0 failed.

command	exit	its log's closing line
cargo run -- --build-only	0	08:33:23 Build finished.
cargo run -- --ci host	0	08:50:36 [ci] Host: 77 step(s), all green
cargo test --test toyos-build -- machine_shutdown	0	08:39:23 test result: ok. 2 passed, 2 total (17.9s; workers: 15s building, 15s testing)
cargo test --test toyos-build -- screen_fatal_halt_composited	0	08:40:17 test result: ok. 1 passed, 1 total (53.8s; workers: 44s building, 9s testing)
cargo test --test toyos-build -- virt_user_mode (the AArch64 kernel)	0	08:41:01 test result: ok. 1 passed, 1 total (43.7s; workers: 40s building, 3s testing)

The guest tests chosen are the QEMU boots that map and release regions: every boot's programs map their log ring, and the composited screen test maps the scanout buffers.

The T14, at 58b768a

The binaries that exercise region lifetime directly ride the T14's shared boots and no QEMU registration, so the T14 is their only reading. Three boots, each whole, since every member that makes an inbox goes through map_into and InboxRef's unmap_from; the shipping set is chunked into two images, so the review's two boots are three. Staged by the implementer from the clean tree at 58b768a with cargo test --test toyos-build -- --metal --metal-readback <dir> (exit 2, closing line [metal] staged 30 image(s); no filter selects the shared boots whole, so the whole profile was staged and the 27 images nobody asked for were removed). Booted by the orchestrator, one boot per image, each image's sha256 checked against the request before it was flashed:

boot	command	exit	image sha256	===TEST_END lines	of them exit=0	the rows the review named, each exit=0
shared	cargo run --bin toyos-metal -- --image <dir>/shared/image.img --readback <dir>/shared --fat32-check	0	fe56f9ae0929006d6cf3b35ddc5fd08c5e6956eb69f3ce89243330fa37271cca	62	62	test_rs_abuse_shared_grant
shared-2	cargo run --bin toyos-metal -- --image <dir>/shared-2/image.img --readback <dir>/shared-2 --fat32-check	0	789cd7391c6837977677a834a4e95b72ad9b746c7e01d4acb54ceb208c7f1dea	22	22	test_rs_spawn_image_object
shared-debug	cargo run --bin toyos-metal -- --image <dir>/shared-debug/image.img --readback <dir>/shared-debug --fat32-check	0	d81a0458f52bd0215877fcbcdc62d5a15621fd21fa03e4a319a23d7771aeb376	7	7	test_rs_handle_lifetime, test_rs_shm_release_reclaims

The orchestrator's record of the run is #762 (comment), and round 2's review read the three readbacks themselves: each verdict.txt is passed, and the names on each boot's exit=0 lines are exactly the test_rs_* jobs its image's system-*.toml declares.

Landing order, as the orchestrator ruled it: this pull request lands before #761. Its T14 reading is then of the kernel that lands: no byte outside issues/ has moved since 58b768a, and this branch does not merge origin/main again. #761 then merges main and owes its own readings at its merged head.

Unsure of

• The filed issue is a trace, and so is what this body adds to main's poll issue: neither interleaving was executed, and neither has an actuator that could.
• The harness's by-name judge was not run over the three readbacks, and is not owed. For a shared member the judge is Readback::job_passed (tests/common/metal.rs), the exit code off that member's ===TEST_END line, which is the line read here, against a set the review compared with each image's own job list. What the judge adds per boot over toyos-metal's verdict is stop_completed and log_reached_the_stick, both read by the review off each loader.log, and the boot and panel timings against the machine's record, which this change makes no claim about.
• cargo run -- --ci host was not run again at 933d291: the commit since moves two files under issues/ and nothing else. CI's host, toolchain and guest are skipped on a draft, and a skipped check is not a reading.

Size

git diff --shortstat origin/main...933d291e7: 4 files, +112 −45. Production: 3 files, +67 −45 (Held's two verbs +10, the module header +4, the rest is map_into and unmap_from re-nested under with_mut). Tests: 0. Issues: one filed, +45.

Closes issues/an-shm-map-racing-the-last-close-publishes-a-mapping-after-teardown.md, carried here from #754's branch in the first commit and deleted in the second; #754 was closed without landing.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RvnWQFcMuGqTHYhvSnTe8A

[Japabu]

The negative control's probe, applied as a checked patch to 8340830 and restored after each arm. Never landed.

diff --git a/kernel/src/main.rs b/kernel/src/main.rs
index d9efe43de..9f0326cdb 100644
--- a/kernel/src/main.rs
+++ b/kernel/src/main.rs
@@ -497,6 +497,22 @@ pub(crate) unsafe extern "C" fn kernel_main(kernel_args: &KernelArgs) -> ! {
     gpt::probe_usb_disks();
     rootfs::hold_source();
 
+    // PROBE, never landed: `SYS_SHM_MAP`'s steps with the last close inside its window. `shm` is
+    // the reference the syscall cloned out of the table; the one handle goes and its hook runs,
+    // as a sibling thread's close does; then the syscall maps.
+    {
+        use crate::object::{shm::SharedMemObject, HandleEntry, KObjectRef};
+        let shm = SharedMemObject::create(crate::mm::PAGE_2M).expect("probe: a region");
+        let space = crate::mm::paging::AddressSpace::new_user().expect("probe: an address space");
+        let pt: crate::process::PageTables = alloc::sync::Arc::new(crate::sync::Lock::new(space));
+        drop(HandleEntry::new(KObjectRef::SharedMem(shm.clone()), toyos_abi::handle::Rights::MAP));
+        crate::object::drain_zero_handles();
+        let answer = shm.map_into(toyos_abi::Pid(1), &pt);
+        log!("shm-probe: a map after the last handle's teardown answered {answer:x?}");
+        drop(shm);
+        log!("shm-probe: the region was freed and the kernel is running");
+    }
+
     #[cfg(feature = "boot-actuators")]
     if actuator::leak_rollback_selftest() {
         leak_selftest::run();

Red arm (the fix's kernel/ diff reverted, then the probe): cargo test --test toyos-build -- --nocapture machine_shutdown_short_stop, EXIT=1. The guest's serial log:

[ 3.992 cpu0 kernel] shm-probe: a map after the last handle's teardown answered Ok(ffff400000)
[ 3.993 cpu0 kernel alert] PANIC: panicked at src/object/shm.rs:186:9:
shm koid 4 freed with a live mapping: the zero-handle hook did not run, so the pages go back to the PMM under somebody's window
[ 3.995 cpu0 kernel]   Backtrace:
[ 3.996 cpu0 kernel]     0xffff80007afdca5c  core::panicking::panic_fmt+0x2c
[ 3.997 cpu0 kernel]     0xffff80007af26794  core::ptr::drop_glue::<kernel::object::shm::SharedMemObject>+0x144
[ 3.997 cpu0 kernel]     0xffff80007aeece72  <alloc::sync::Arc<kernel::object::shm::SharedMemObject>>::drop_slow+0x12
[ 3.997 cpu0 kernel]     0xffff80007af86d28  kernel::kernel_main+0x1568
[ 3.998 cpu0 kernel]     0xffff80007af5d411  _start+0x21
[ 3.998 cpu0 kernel]   Contexts: cpu0 crashed at sp=0xffff80007bb625b0, asking about ctx 0x0
[ 3.998 cpu0 kernel]   cpu0 is on ctx 0x0 (never switched, or not a context)
[ 3.999 cpu0 kernel alert] panic: rebooting in 60 s, timed by the calibrated clock

Green arm (the probe on the fix): same command, EXIT=0. The guest's serial lines:

08:38:32 [serial 0] [ 4.819 cpu0 kernel] shm-probe: a map after the last handle's teardown answered Err(Gone)
08:38:32 [serial 0] [ 4.819 cpu0 kernel] shm-probe: the region was freed and the kernel is running
08:38:32 test result: ok. 1 passed, 1 total (18.7s; workers: 13s building, 6s testing)

[Japabu]

Review round 1 of #762 at 83408305e, against origin/main 017451624. Read only: the diff, the four changed files whole, every caller of the mapping list, the implementer's logs on disk. Nothing was run.

Net lines (git diff --shortstat origin/main...83408305e): 4 files, +108 −45. Production +67 −45 (kernel/src/object/shm.rs, kernel/src/object/mod.rs, a doc comment in toyos-abi/src/syscall.rs); tests 0; issues +41. The production growth is accepted: it is the Option around the list and the two verbs that reach it.

BLOCKER

• PR body, "Not run" — shm_release_reclaims, handle_lifetime, abuse_shared_grant and spawn_image_object are guest tests the change reaches and none has a reading at this head — Evidence asks every one green, and they ride no QEMU registration. Owed, by row of shared_metal (tests/toyos.rs:1022): boot shared (shipping kernel, tests/testcases) for test_rs_abuse_shared_grant and test_rs_spawn_image_object; boot shared-debug (build::TEST_KERNEL) for test_rs_handle_lifetime and test_rs_shm_release_reclaims, both on ACTUATOR_TESTS (tests/toyos.rs:48-49). Both boots whole are the reading that counts: every member that makes an inbox goes through map_into and InboxRef's unmap_from. The T14 is the orchestrator's; the command, exit code and log go in the body at the head that lands.
• issues/a-device-call-acts-on-whoever-holds-its-claims-slot-by-then.md — one subject with issues/a-pci-call-in-flight-names-its-function-by-a-slot-the-next-claim-reuses.md, which Three audit claims traced: a BAR asked for twice panics the kernel, netstack keeps a dead client's socket, and a PCI call's slot is not its claim #755 (in the merge queue) files: the same pci_slot → with_bound window, the same reuse through release and the next claim, the same exit (the call acts on its claim's binding or is refused). Three audit claims traced: a BAR asked for twice panics the kernel, netstack keeps a dead client's socket, and a PCI call's slot is not its claim #755's names an owner and an exit a test can fail; this one names no owner and an exit only reading checks. This file goes, with its citation in the second commit's message and in the body's "Does not hold" bullet, which then points at Three audit claims traced: a BAR asked for twice panics the kernel, netstack keeps a dead client's socket, and a PCI call's slot is not its claim #755's slug. Its one sentence Three audit claims traced: a BAR asked for twice panics the kernel, netstack keeps a dead client's socket, and a PCI call's slot is not its claim #755's file does not have, the untraced ISA/ACPI row (DeviceClaim::isa_row, isa::bound_to), is either traced here and filed as its own narrow file with an owner and an exit, or left out; it is not appended to a file this branch does not own.

NOTE

• Brief (1), the window, read line by line: closed. The list has four touch points and all four take the one Held lock: map_into (shm.rs:163), unmap_from (:170), the hook's take (:184), mapped_nowhere (:134). A map either pushes before the take and is torn down and flushed by the hook, or finds None and answers Gone before pt.lock(). The hook's take is the only one, and HandleEntry::drop's retired.swap assert (handle.rs:138) is what makes expect("the zero-handle hook runs once") a kernel-bug panic and not a userland one. The batch's KObjectRef holds an Arc across the hook (mod.rs:287), so the pages outlive the teardown and its shootdown. A map in another process holding its own handle keeps the count above zero, a handle in a connection's queue is a HandleEntry and counts, and a region no handle named (the inbox's) never retires. Lock order is what main has: list lock, then a page-table lock, in map_into and unmap_from; the hook takes the page-table locks with the list lock released; no path takes the process-data lock under either (sys_shm_map drops it before map_into, HandleEntry::drop only enqueues).
• Brief (2), Held: not weakened. release is still take-under-the-lock, drop outside it. take and with_mut are pub(crate) with one caller each; no other Held user's resource is reachable through them that was not through release and with.
• Brief (3), no landed test: none is owed. A host test of take-then-with_mut asserts Option::take and Option::as_mut. The probe does not land: it is kernel code shipped for a test alone, guarding two lines a reader checks (shm.rs:163, :184). The negative control CLAUDE.md asks of high-risk code is in the PR's comment at this head, both arms, with the red arm's revert byte-identical to the branch's kernel/ diff (compared against fix-kernel.patch), and the oracle is main's own assert.
• PR body, "Gates" — the five rows give command and exit code and no log. The logs are on the implementer's disk at this head and say what the table says ([ci] Host: 77 step(s), all green; machine_shutdown 2 passed; screen_fatal_halt_composited 1 passed; virt_user_mode 1 passed); the body quotes each one's closing line.
• PR body, "Who owns what" — "a claim's BAR windows must go when the claim's handle goes" is false of the tree: a BAR window is its own SharedMemObject and goes with that object's last handle (sys_device_bar_map, kernel/src/syscall/device.rs:193), which is the subject A claim keeps where its BARs are and no object over them: a BAR asked for again after its handle closed no longer panics the kernel, and two answers held at once map apart #761 files.
• For the record, wt/toyos-barremap (A claim keeps where its BARs are and no object over them: a BAR asked for again after its handle closed no longer panics the kernel, and two answers held at once map apart #761): this change requires only that a retired SharedMemObject is never handed out again, and A claim keeps where its BARs are and no object over them: a BAR asked for again after its handle closed no longer panics the kernel, and two answers held at once map apart #761 at its present head already mints one per ask and deletes Bound::bars. On main the cached object's second handle dies in HandleEntry::new's assert before any map, so this branch changes nothing there. The two branches touch kernel/src/object/mod.rs and toyos-abi/src/syscall.rs in different hunks; whichever lands second rebases and re-measures.
• Off the fence, unchanged by this branch, not found in issues/: nothing but InboxRef's drop calls unmap_from, so a process that exits with a region mapped leaves its (Pid, PageTables, UserAddr) entry in the list, holding that address space's Arc, until the region's last handle goes anywhere. To be traced and filed by whoever owns the object layer, not fixed here.

SEND BACK

[Japabu]

T14 at head 58b768a03 (orchestrator's run; the three images staged by the implementer from the clean tree, each sha256 checked against the request and printed by the command that flashed it). Each boot is read whole, by toyos-metal's exit and the ===TEST_END lines of its readback; the harness's by-name judge was not run over them.

boot	image sha256	toyos-metal	===TEST_END lines	of them exit=0
shared	fe56f9ae…37271cca	exit 0	62	62
shared-2	789cd739…8c7f1dea	exit 0	22	22
shared-debug	d81a0458…71aeb376	exit 0	7	7

The four rows the review named, each exit=0: test_rs_abuse_shared_grant (shared), test_rs_spawn_image_object (shared-2), test_rs_handle_lifetime and test_rs_shm_release_reclaims (shared-debug).

[Japabu]

Review round 2 of #762 at 58b768a03, against origin/main 2e781a49d. Read only: the diff, the changed files whole, the two new issues against the code they cite, issues/ on origin/main, the three T14 readbacks on disk, the harness's judge. Nothing was run.

Net lines (git diff --shortstat origin/main...58b768a03): 5 files, +157 −45. Production +67 −45, unchanged since round 1 and accepted there; tests 0; issues +90.

Round 1's BLOCKERs

• The T14 boots: CLOSED. Read from the readbacks, not from the comment's table. Each boot's verdict.txt is passed; the names on its ===TEST_END … exit=0=== lines are exactly the test_rs_* jobs its image's system-*.toml declares (62 of 62, 22 of 22, 7 of 7, comm empty both ways), none with another exit; the four named rows are among them (abuse_shared_grant in shared, spawn_image_object in shared-2, handle_lifetime and shm_release_reclaims in shared-debug). No kernel panic line in any log; the six panicked at lines in shared-2 are std_unwind's own. Each pass after the reset reads DONE and a tail ending Rebooting. with stop: 19 of 19 userland thread(s) stopped … 0 of N userland block operation(s) still open. shared-debug booted a different kernel (2756600 bytes against 2416840), as it must.
• The duplicate device-slot issue: CLOSED. issues/a-device-call-acts-on-whoever-holds-its-claims-slot-by-then.md is in no tree of the branch's diff, and git grep at the head finds neither its slug nor the closed shm issue's; the fix commit's message and the body point at Three audit claims traced: a BAR asked for twice panics the kernel, netstack keeps a dead client's socket, and a PCI call's slot is not its claim #755's file.
• git diff 83408305e 58b768a03 -- . ':(exclude)issues' is empty, as claimed: the code round 1 read line by line is the code at this head.

BLOCKER

• issues/a-poll-in-flight-on-an-isa-claim-is-registered-on-the-rows-next-claim.md — one subject with issues/a-poll-registered-racing-its-own-close-outlives-the-release.md, which main has had since 2026-09-26 — the same window (the handle resolved and the object cloned out in kernel/src/inbox/mod.rs, then registered on a per-device static watch with no lock held), the same sibling close and release's cancel_polls inside it, the same harm (the next holder's interrupt completes the old poll: another process's device activity across the boundary), and an exit already written for every claim, not for PCI alone: "a poll cannot reach a watch whose object has ended", with a guest test in which a second claim "sees no completion arrive in the first one's ring", which also covers the at-once fire through has_data. The new file is true of the code (DeviceClaim::isa_row is a plain field the release does not clear, ops.rs:284 and :801 answer from the row, isa::release clears MINTED, claim_row mints again once BOUND is NOBODY, a claim's handle carries TRANSFER), and its sentence "the PCI half of the shape is …a-pci-call-in-flight…" is not: the PCI half of the poll is the older file. This file goes, as round 1's did. What it adds to main's file — the ISA and ACPI rows have the window only where the binder moved the handle on and ended, and the calls on the claim do not have it — stays in the body's bullet, which then cites main's slug; the branch does not edit a file it does not own. Round 1 offered "its own narrow file" without having searched for the poll's; that offer was wrong.

NOTE

• PR body, "Owed: the T14" and "Not run" — stale: the boots were run at this head. The body takes the reading, per boot the cargo run --bin toyos-metal -- --image … --readback … --fat32-check command, its exit 0, the image sha256 and the 62 / 22 / 7 exit=0 counts, and loses "Not run". With the BLOCKER it is the body's only other change.
• Whether the by-name judge is owed: no. For a shared member the judge is Readback::job_passed (tests/common/metal.rs:482), the exit code off that member's ===TEST_END line, which is the line read here, against a set I compared with the image's own job list. What the judge adds per boot over toyos-metal's verdict is stop_completed and log_reached_the_stick, both read above off each loader.log, and the boot and panel timings against the machine's record, which this change makes no claim about. The body's "Unsure of" line can say so.
• issues/a-region-keeps-the-address-space-of-every-process-that-ended-with-it-mapped.md — true of the code: unmap_from's one caller is inbox/mod.rs:84; teardown_resources (process.rs:1028) closes handles and touches no list; the entry's PageTables Arc holds the AddressSpace whose drop is the only return of its PcidGuard (arch/x86_64/paging.rs:322); new_user answers None at exhaustion and loader/mod.rs:435 refuses the spawn ResourceExhausted; sys_shm_create's handle carries MAP, DUP and TRANSFER; pids are never reissued. Not a duplicate of issues/the-compositor-keeps-a-committed-regions-mapping-for-as-long-as-the-client-does.md: that exit ends a view at a close, this one at a process's end, and its harm is every spawn on the machine refused. Owner and exit stand; a test can fail the exit.
• Same file, last sentence — narrower than the cited exit: the compositor issue's exit also reaches a process that closed its handle before it ended (unmapped at that close); the residue is a handle moved on by SYS_HANDLE_SEND, which is no close.
• CI at this head: host, toolchain and guest are SKIPPED (run 37754056566, draft). A skipped check is not a reading.

The sequencing with #761

#761 lands first; this branch then merges origin/main. At the merged head the body owes, each with command, exit code and log at that head:

• cargo run -- --ci host.
• bar_map_again, whole, with whatever arm A claim keeps where its BARs are and no object over them: a BAR asked for again after its handle closed no longer panics the kernel, and two answers held at once map apart #761's fix round adds: two answers held together is two SharedMemObjects over one frame in one address space, each with its own Held list, and the first one's drop is this branch's hook.
• machine_shutdown, screen_fatal_halt_composited, virt_user_mode, as now.
• The three T14 boots again. The reading at 58b768a03 does not carry: the merge brings a kernel/src/pcidev/mod.rs hunk, so both kernels differ in bytes from the ones booted and the request's own line says a commit after 58b768a03 voids the images. The argument that carried 83408305e to 58b768a03 was that no byte outside issues/ moved; it does not cross a kernel hunk. The four named rows have no QEMU registration, so no CI check reaches them and the T14 is their only reading.
• The negative control is not owed again provided git diff 58b768a03 <merged> -- kernel/src/object/shm.rs kernel/src/object/handle.rs kernel/src/syscall/ipc.rs is empty and kernel/src/object/mod.rs differs by A claim keeps where its BARs are and no object over them: a BAR asked for again after its handle closed no longer panics the kernel, and two answers held at once map apart #761's header lines alone: both arms were measured on one base, and A claim keeps where its BARs are and no object over them: a BAR asked for again after its handle closed no longer panics the kernel, and two answers held at once map apart #761 touches neither the map nor the hook.

The landing then rests on host and guest / suite concluding success on the ready pull request at that head and again in the merge queue, and on the T14 reading in the body, which no check runs.

SEND BACK

[Japabu]

Review round 3 of #762 at 933d291e7, against origin/main 2e781a49d (fetched now; it is also the merge base). Read only: the one commit since 58b768a03, the remaining issue whole, the body, the T14 comment, issues/README.md, #761's diff at 8a6dc0be3. Nothing was run.

Net lines (git diff --shortstat origin/main...933d291e7): 4 files, +112 −45. Production 3 files, +67 −45, unchanged since round 1 and accepted there; tests 0; issues +45.

Round 2's BLOCKER

• The duplicate poll issue: CLOSED. git diff 58b768a03 933d291e7 deletes issues/a-poll-in-flight-on-an-isa-claim-is-registered-on-the-rows-next-claim.md whole; git grep at 933d291e7 for its slug, for poll-in-flight and for its heading finds nothing (exit 1); git diff --name-status origin/main...933d291e7 -- issues is one line, the region issue added. The body's ISA and ACPI bullet cites main's issues/a-poll-registered-racing-its-own-close-outlives-the-release.md, which exists at the head, and the branch does not edit it.

What the T14 reading is of

• git diff 58b768a03 933d291e7 -- . ':(exclude)issues' prints nothing, exit 0; one commit, parent 58b768a03, no merge. git diff 83408305e 933d291e7 -- . ':(exclude)issues' prints nothing either. The kernel booted three times at 58b768a03 (comment 6056578038) is this head's kernel, and the code the gates and both arms of the negative control measured at 83408305e is this head's code.
• It stays the kernel that lands only while main is 2e781a49d when the queue takes this: the queue's merge is then this head's tree. Anything that lands first and moves a byte under kernel/, toyos-abi/ or what the three images are built from voids the reading, as round 2 said of a merge.

BLOCKER

None.

NOTE

• PR body, last paragraph — "Three audited kernel races recorded, traced and unexecuted: an IPC rollback's expect, chdir against open, an shm map against the last close #754 still adds it and will conflict as modify/delete on that file" is false of the record: Three audited kernel races recorded, traced and unexecuted: an IPC rollback's expect, chdir against open, an shm map against the last close #754 is CLOSED. The sentence goes.
• issues/a-region-keeps-the-address-space-of-every-process-that-ended-with-it-mapped.md, last sentence — now true of the cited exit and of the code: the compositor issue's exit unmaps a process's view "at the close of its last handle", teardown_resources closes handles, and the residue is a handle moved on by sys_handle_send (kernel/src/syscall/ipc.rs:376). Every file it cites exists at the head. Nothing owed.
• The rest of the body is true of the head: the size figures match the shortstat, the T14 section carries per boot the command, exit 0, the image sha256 (each agreeing with the comment's abbreviated one) and the 62 / 22 / 7 counts, "Owed" and "Not run" are gone, and the by-name judge is answered as round 2 answered it.

The order: this lands before #761

Nothing is wrong with it, and it is the cheaper order.

• This branch alone on main leaves a BAR asked for twice exactly as main has it today: pcidev::bar_object still hands the retired object to ops::install, and HandleEntry::new's assert fires there, before any map_into and before the hook could run a second time, so on_zero_handles's new expect("the zero-handle hook runs once") is never reached on that path. Same panic, same three calls, already filed on main. Not worse.
• A claim keeps where its BARs are and no object over them: a BAR asked for again after its handle closed no longer panics the kernel, and two answers held at once map apart #761 on top is the composition that is right: every ask makes a fresh SharedMemObject with its own Held list, so no retired object is handed out again, which is the one thing the body's note to A claim keeps where its BARs are and no object over them: a BAR asked for again after its handle closed no longer panics the kernel, and two answers held at once map apart #761 asks of that path; and a map through a stranded Arc of a BAR object answers Gone instead of landing in an emptied list, which A claim keeps where its BARs are and no object over them: a BAR asked for again after its handle closed no longer panics the kernel, and two answers held at once map apart #761 alone would have left. Not worse either way; the reverse order would have had main carry that stranded-Arc map for the interval.
• A trial merge of the two heads (git merge-tree --write-tree 933d291e7 origin/wt/toyos-barremap) is clean, exit 0, including the two files both touch, kernel/src/object/mod.rs and toyos-abi/src/syscall.rs.
• What round 2 hung on this branch's merged head moves to A claim keeps where its BARs are and no object over them: a BAR asked for again after its handle closed no longer panics the kernel, and two answers held at once map apart #761's: cargo run -- --ci host, and bar_map_again whole with its two-answers-held arm, which is where two objects over one frame in one address space first meet this branch's hook. Both at the head that has merged main with this in it, each with command, exit and log.
• One thing for A claim keeps where its BARs are and no object over them: a BAR asked for again after its handle closed no longer panics the kernel, and two answers held at once map apart #761's reviewer, not decided here: the four region rows will have been read on the T14 on a kernel without A claim keeps where its BARs are and no object over them: a BAR asked for again after its handle closed no longer panics the kernel, and two answers held at once map apart #761's pcidev hunk and never on the combined one. A claim keeps where its BARs are and no object over them: a BAR asked for again after its handle closed no longer panics the kernel, and two answers held at once map apart #761's kernel diff is bar_object and a header line, and touches neither map_into, the hook nor handle.rs, so the rows' path differs only where a member of those boots maps a BAR. Whether one does is what "no T14 row" rests on, and I did not read A claim keeps where its BARs are and no object over them: a BAR asked for again after its handle closed no longer panics the kernel, and two answers held at once map apart #761 for it.

What the landing rests on

• host, toolchain and guest / suite concluding success, not skipped, on the ready pull request at 933d291e7, and again in the merge queue. All three are SKIPPED today (run 37755710416, draft), which is no reading.
• The T14 reading in the body, which no check runs, under the condition above.
• The negative control in the body, both arms on 83408305e.
• --ci host not rerun since 83408305e: accepted. The diff since is issues/ alone. The host steps that read that directory resolve a manifest's or a build reason's cited issue (src/userlandhost.rs, src/build.rs:2908), and nothing in the tree cites either file this branch's issue commits touched; toyos-checks is reported at the head, exit 0, 36 passed, and tests/checks.rs and tests/checks/ hold 36 #[test]s. CI's host on the ready pull request is the reading at this head, and a red there sends the branch back whatever this line says.

LAND