admin/LithosAnanake
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add Artemis stress test for detecting cache aliasing bugs. Include statistical hypothesis evaluations, fix validation data, and run reports for validation across architectures.

Browse Source 
Signed-off-by: Robert Allan James <robert.allan.james@gmail.com>
This commit is contained in:
Robert Allan James
2026-08-02 14:49:52 -04:00
parent 148c4aa12c
commit 1cb68502fb
44 changed files with 5610173 additions and 2680 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/ARTEMIS.md
+29
View File
@@ -177,6 +177,35 @@ Acceptance criteria status, verified 2026-08-02:
Not done: everything under "FUTURE MATERIAL" below (zones, USB hot-plug,
ACL records, PKI) — that line remains accurate and unchanged.
### Surface Stress Test — permanent fixture, found a real bug (2026-08-02)
`ART-STRESS-TEST ( seed reps -- )` (`capsules/artemis/init.4th`, blocks 4160–4173) is a permanent, on-demand exercise of
the block-storage path across the whole data pool: `reps` distinct random blocks (coprime-stride walk, collision-free,
never touches anything already allocated by someone else), written, then verified after all writes complete so real
cache-eviction traffic gets forced through both caching layers. Every trial emits a `[ARTSTRESS]`-tagged CSV row to the
serial log (`HEADER`/`SUMMARY` markers make a truncated run unmistakable). Invoke as
`ART-STRESS` (fixed seed, 50 reps) or `<seed> <reps> ART-STRESS-TEST`. Not wired into the boot sequence — block 4170
carries the entry point commented out (`\ ART-STRESS`), same disable-by-default convention as
`ACL.4th`'s self-activation toggle, so ordinary boots pay nothing for it.
Its first completed run found a real, pre-existing data-corruption bug on amd64: 25 of 50 trials (50%) returned the
wrong byte pattern. Root cause, confirmed by source review and fixed in `src/word_source/block_words.c`
(not Artemis-specific — this is shared block-subsystem plumbing every VM using `BLOCK`/`UPDATE`/`FLUSH` goes through):
the VM-level "window" cache (`vm->blk_vm_cbuf[]`) stores a raw pointer directly into one of the block-subsystem's eight
`cache_slot_t` devblock-cache entries (`block_subsystem.c`). That cache's own FIFO eviction relocates entries via
struct-copy (`slot->cache[i] = slot->cache[i+1]`) once more than eight distinct devblocks are touched in one VM
session — the *addresses*
of `cache[0..7]` never move, but what they hold does, silently, aliasing any window pointer captured before the shift.
No prior test had ever touched enough distinct devblocks in one session to trigger it. Fixed by re-resolving the buffer
pointer by logical block number (`blk_get_buffer`)
immediately before every write-through-cache-pointer operation in
`block_word_update`, `blk_vm_evict`, and `blk_vm_flush_all`, instead of trusting a pointer captured earlier — confined
to the consumer side, no change to the block subsystem's cache architecture. Independent of, and predates, the
`BLK-CONFIRM-FORMAT` fix above; neither touches the other's code path. Re-verified 50/50 on amd64, aarch64, and riscv64
after the fix. Full write-up with hypothesis-tested analysis (a naive "consecutive writes fail together" reading did not
survive a formal runs test — see the report for what did and didn't hold up):
`experiments/artemis_stress/analysis/report/artemis_stress_report.pdf`.
---
## What Artemis Owns