diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-20 16:52:11 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-20 16:52:11 -0400 |
| commit | ebc6386cd769f6017e6f48296eeb5e5ae0d52c80 (patch) | |
| tree | e133e14f8eea90c44928b62c9f15b53082cce536 /tools/gr-regs/README.md | |
| parent | a1455655b68f5fd9710f764be8e6afbed5b2a81c (diff) | |
| download | open-iov-ebc6386cd769f6017e6f48296eeb5e5ae0d52c80.tar.gz open-iov-ebc6386cd769f6017e6f48296eeb5e5ae0d52c80.zip | |
sema: pin-wins wave - a fresh pin re-homes the landing table (svc_handle_map_add) and wins over the ledger in svc_gr_page_note, svc_gr_data_fill and svc_fill; gate the displaced-pin fan-out on a current pin match
Root cause class (sub-agent audit + r371 log forensics): the landing table
(ledger) moved only on host writes, so a VA re-pinned to a NEW page (CUDA
reuses VA ranges across processes) kept resolving to the OLD, freed page.
Every later write through that entry landed on memory the guest kernel had
since reused - the r371 mail client's guest oops (NULL page array in
nv_free_system_pages, 8 zero bytes) is this class. Fixes: (1) svc_handle_
map_add repairs a disagreeing ledger entry from the fresh pin (PIN-REPAIR);
(2) svc_gr_page_note and svc_gr_data_fill keep a live pin over the ledger
(PIN-WINS); (3) svc_fill checks the pin before the ledger fallback; (4) the
pool alt fan-out writes the displaced page only while the current pin still
names it (alt_skip). New diag: pinrep= alt_skip=.
Diffstat (limited to 'tools/gr-regs/README.md')
0 files changed, 0 insertions, 0 deletions
