chrg6 e4f10a5a02 Log the hang watch's list of guest thread waits after the kernel lock is released, not while it is held. ...

The review of the hang watch found that kernel.c kern_wait_report called rt_log for up to 16 lines while it held the
kernel lock G. When the log queue is full and the log thread is stuck holding its write lock, one of the stalls the
watch reports, the put that drains the queue waits there with G held, which turns a log stall into a freeze of every
guest thread. wait_watch (NX2NAVI_WAIT_WATCH_S, off by default) had the same pattern.

wait_pass now formats its lines into a buffer of the caller's (WAIT_LINE_CAP bytes a line, room for the 16 or 24 lines
asked for), and kern_wait_report and wait_watch log them with the new wait_lines_log after unlock. A line that finds
no room ends the pass unmarked, so wait_watch logs it at its next pass. The lines read as before.

Not reproduced before the change (it needs a stalled log thread beside a report). tests/hang_watch_check.py checks
statically that wait_pass logs nothing and that both callers log only after unlock; the check fails on the code
before this change and passes after it, and the program's cases pass. The compile check of kernel.c passes with no
-Wall warnings.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-11-13 18:43:24 -05:00

110 KiB

Raw Permalink Blame History

View Raw