summaryrefslogtreecommitdiffstats
path: root/tools/guest-diag/wall2
diff options
context:
space:
mode:
authorArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-25 14:09:57 -0400
committerArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-25 14:09:57 -0400
commit74c59db9c701a0e14d7210edfef9d13c086dcf87 (patch)
tree07dd375e2951b58387b2279f81a61d82fac7198c /tools/guest-diag/wall2
parent3c73a49d9c1ffae87ebdca77c546a77df175e677 (diff)
downloadopen-iov-74c59db9c701a0e14d7210edfef9d13c086dcf87.tar.gz
open-iov-74c59db9c701a0e14d7210edfef9d13c086dcf87.zip
wall2 session 101: auth-tag wait loop decoded (sema at pChannelBufferMemdesc+finishPayloadOffset+4, exits when GetPtr passes nextPut); perf trace (no-ptrace) shows the 10ms futex retry + a transient open/read(299)/close polling reader; next = catch the transient fd path and write the sema
Diffstat (limited to 'tools/guest-diag/wall2')
-rw-r--r--tools/guest-diag/wall2/README-session77.md23
1 files changed, 23 insertions, 0 deletions
diff --git a/tools/guest-diag/wall2/README-session77.md b/tools/guest-diag/wall2/README-session77.md
index 2013c2f..92f3bc3 100644
--- a/tools/guest-diag/wall2/README-session77.md
+++ b/tools/guest-diag/wall2/README-session77.md
@@ -810,3 +810,26 @@ target it; the service's release applies would write the sema if the VA
resolves). (3) The registered FB userd offsets being zero suggests the
client's kernel maps the userd through a VA whose PA the discovery misses;
the diff-watch (two samples around activity) remains the fallback proof.
+
+**28. Session 101: THE LOOP SEMANTICS + perf trace (NO-PTRACE SYSCALL TRACING).**
+The wait loop decoded exactly (sec2_utils.c:420-441):
+`while (nextPut == pSec2Utils->authTagGetIndex) { gpuCheckTimeout();
+authTagGetIndex = _sec2utilsUpdateGetPtr(); osSpinLoop(); }` - it exits
+when the memdesc sema (u32 at pChannelBufferMemdesc +
+authTagBufSemaOffset; authTagBufSemaOffset = finishPayloadOffset + 4)
+advances past nextPut; it also has a GPU timeout that would error out.
+perf trace on the spun client (no ptrace!) revealed the live pattern:
+tid 1793 = a 10ms-timed futex loop (WAKE val=1 then
+WAIT_BITSET|CLOCK_REALTIME 10ms - the paced retry); tid 1788 = repeated
+`openat -> read(fd, 299 bytes) -> close -> futex-wait` - a transient-fd
+POLLING READER of a small blob (the fd is opened and closed each cycle, so
+fd 28 no longer exists; the client's persistent fds: /dev/nvidia-modeset
+(10), /dev/nvidia0 (11/12/14/15), GLCache .toc/.bin (16/17), memfd
+\"allocation fd\" (18)). The 299-byte read is the likely userland face of
+the memdesc read path (the 24% channelReadChannelMemdesc hot loop).
+NEXT: (a) catch the transient fd path by sampling `ls -l /proc/<pid>/fd`
+every ~0.2 s in a loop around the burst (or perf trace -s during a burst);
+(b) if it is a driver read() of the memdesc, resolve its buffer and write
+the auth-tag sema value (advance past nextPut) via the RAM file; (c) the
+loop timeout (gpuCheckTimeout) may eventually error the client - the write
+must land first.