vgsp-sema r541: hold a GR forward whose data page has an unexecuted device write

Live root cause of the smiley/streams2/streams_events readback lottery
(r539): smiley pass 2 verified a2 + b1 and pass 4 verified a4 + b2 - each
even pass's launch read the PREVIOUS even pass's b page. The b H2D's
release completed the client's synchronous cudaMemcpy while the copy op
itself was still held (b's svc_copy executed at 294026.818; launch 2's
engine read at ~294026.3), so the client legitimately submitted the launch
against a shadow page the H2D had not written yet. Passes 1/3 looked
'correct' only because passes 2 and 3 share the same b formula.

Fix, as recommended in CONT.100/94: a device-dst copy/fill that fails to
execute this pass (rc=-ENOENT) records its destination VA page in
svc_dstpend[] with a 10 s stamp. svc_gr_request, right after the fill and
before any submit, checks the launch's filled data pages against the
table (svc_gr_dstpend_overlap); a hit returns the busy-defer verdict, so
the pump holds the entry in its bounded retry window and re-captures once
the copy has run - the record clears on the copy's success. The 10 s
window restores the historical forward when the copy never lands, so the
guard can only delay a launch, never hang it.

0 files changed, 0 insertions, 0 deletions