summaryrefslogtreecommitdiffstats
path: root/kernel/firmware_analyzer.h
diff options
context:
space:
mode:
authorArthur Hanson Rasmusson <arthur@vgpu.io>2026-09-30 20:33:26 -0400
committerArthur Hanson Rasmusson <arthur@vgpu.io>2026-09-30 20:33:26 -0400
commitdce73a6b32edfb06383e868aa563206ca446c0a3 (patch)
treec364e0213371a5d48819a98d82dde57326e15ca1 /kernel/firmware_analyzer.h
parent7dc835539911b7519c5d47f8b8df55a481b546a0 (diff)
downloadopen-iov-dce73a6b32edfb06383e868aa563206ca446c0a3.tar.gz
open-iov-dce73a6b32edfb06383e868aa563206ca446c0a3.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 'kernel/firmware_analyzer.h')
0 files changed, 0 insertions, 0 deletions