vgsp-sema: pair CE push-buffer vmap pages with the right offset; validated rescues repair injections

The CE push-buffer uvm_rm_mem is vmalloc'd as a 4097-page area: one
leading page plus the 4096-page (16 MB) GPU data window, so GPU data
page k lives at vmap page k+1. The kcore chain resolver paired page k
with vmap page k, pinning the adjacent push for every page; the pump
then read the wrong push, decode failed, and the host fell into the
content rescue which crawled one entry per ~2 s (r115: rescue_run=4202,
entry_va=0x12001b18c repeating). Verified against five independent
content-validated rescue anchors (k=20..28, all delta +1), and the vmap
area boundary confirms the extra page (nv_vm_map_pages 4097 pages).

Five fixes:
 - resolve_mem_pins() takes page_off; the CE chain and uvbp push-buffer
   paths pass mem_page_off() (1 when the vmap is exactly 16 MB + 1 page;
   0 for direct-mapped mems like the semaphore pool).
 - a content-validated rescue page now also replaces the injected-pin
   entry (svc_rescue_try / svc_rescue_run_try), so a stale or wrong
   injection can no longer shadow the validated page and re-run the
   rescue on every pass.

Evidence: r115 rescue anchors va 0x120014000->pa 0x12a2e2000 .. va
0x12001c000->pa 0x12a2de000 all at vmap offset k+1; the candidate pages
decode as the adjacent push (wrong semaphore payload) before the fix.

0 files changed, 0 insertions, 0 deletions