diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-09-30 20:33:26 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-09-30 20:33:26 -0400 |
| commit | 82173823d526967c57b1f4581bfc9341f5b1f281 (patch) | |
| tree | 125bb24b281698438ae21a865a0f8053e2872bc1 /scripts/stack_manager.sh | |
| parent | 42c7d536d6746e1f4976a43548a95f546bf032b7 (diff) | |
| download | open-iov-82173823d526967c57b1f4581bfc9341f5b1f281.tar.gz open-iov-82173823d526967c57b1f4581bfc9341f5b1f281.zip | |
sema-svc: validate pushes with the full method encoding; deliver releases the sweep already applied
The runtime client's second push on each UVM copy channel starts with a
NON_INC method (0x60080002, count 8) and its release method sits 0x50 bytes
in. The stream validator accepted only INC (op 1) headers, so the readable
page failed the plausibility gate and every content-rescue candidate for
that VA failed the read-back validation - the client's tracking semaphore
for the push never advanced and the runtime init parked.
- one shared parser (svc_stream_parse) accepts INC/NON_INC (op 1/3),
IMMD_DATA (op 4, header-only), ONE_INC (op 5) and END_PB_SEGMENT (op 7),
and still requires an exact method boundary over the whole entry plus
trailing zero padding - the strict end condition is what keeps the
content rescue safe against firmware/allocator pages
- svc_method_stream_plausible and svc_stream_full_ok both use it, so a real
readable push is decoded directly and a rescued page validates
- the decoder skips NON_INC/ONE_INC methods whole (including their data
words) instead of resyncing word-by-word through the payload, which could
misread data as headers and queue bogus work
Follow-on: the content sweep applies releases from RAM pages ahead of the
pump, so the pump's expected payload was already satisfied when it examined
the entry; the CE grace path then held each entry for the full 8 s window
before consuming it - one grace period per push, serializing the client's
runtime init. The pump now records the expected payload when it first
examines an entry (entry_want) and consumes the entry immediately once the
pool advances past it, on both the unreadable-rescue and the
readable-no-release paths.
Evidence (fresh boot, real releases, watchers + kprobes, no fakes):
cudaGetDeviceCount rc=0 in the runtime client, device-attribute walk
proceeds, pool semaphores advance; before this change the client sat in the
0x20801702 service-interrupt loop for >6 min and never left device init.
Diffstat (limited to 'scripts/stack_manager.sh')
0 files changed, 0 insertions, 0 deletions
