vgsp-sema: completion gate for the counter publish - never publish GP_PUT while entries are outstanding

r205 regression (my 8c634144 + 5de33b14 + m180): victory_mail fails in
13 s (was green on r202), victory_matmul hangs 242 s. Root cause: the
rank-pollution fix made svc_counter_publish target the channel's OWN
completion word (release_pa ?: counter_pa), but the publish writes the
ring GP_PUT - the client's SUBMISSION position - into that word. While
the pump still has entries to run the pushes are not complete, so the
publish short-circuited every client wait. Witness (r205, mail):
'[129589.831085] pub-adv h=0x5c000019 pa=0x1274beff0 val=108 cur=104'
(after 'walk ... put=108 get=104 last=104'): the waited word jumped to
the submitted 108 ~1 s BEFORE the engine ran ('[129590.802500] output
retirement wait: 1/968 pages changed after 372 ms (settled)'), the
release payloads for the remaining pushes were then forward-only-
skipped, the client's sync returned early and it dumped the stale
buffer -> STATUS FAIL. Pre-fix comparison (r202, green): the same
client's waited word (pa=...ff0) advanced ONLY by sequential release
payloads ('rel-apply ... pay=1..108 -> written'), while the publish
targeted the ascending slot (pa=...ec0) nobody polls - so the correct
completion timing came from the releases alone.

Fix: gate the publish on the pump's own consumed position - write the
GP_PUT only when nothing is outstanding (ch->last_get == put, the same
equality the entry loop consumes to; wrap-safe for the 1024-entry
rings). The releases remain the completion authority; the publish is
reduced to its designed role: the catch-up for entries the pump
consumed without decoding a release. The descending autoreg and the
release_pa ?: counter_pa target stay (they are what stops the busy
rank-16 channel's put from polluting rank 3's waited word - the evtest3
fix, still required: pre-fix r202 style would redirect that write back
onto 0x20400ffc0).

1 files changed, 20 insertions, 0 deletions

diff --git a/kernel/gsp_sema_service.c b/kernel/gsp_sema_service.c
index 6a1595e..4a86235 100644
--- a/kernel/gsp_sema_service.c
+++ b/kernel/gsp_sema_service.c
@@ -11498,6 +11498,26 @@ static void svc_counter_publish(struct nv_vgpu_device *vgpu,
 
 	if (!pa)
 		return;
+	/*
+	 * COMPLETION GATE (r205 mail/matmul regression): GP_PUT is the
+	 * client's SUBMISSION position; the pump's last_get is its next
+	 * unconsumed entry. While any submitted entry is outstanding
+	 * (last_get != put) the pushes up to put have NOT all completed, so
+	 * the put must never be published into the completion word: doing so
+	 * short-circuits every client wait (r205 mail: rank-0's word jumped
+	 * to the submitted 108 at last_get=104 - `pub-adv h=0x5c000019
+	 * pa=...ff0 val=108 cur=104` - ~1 s before the engine ran
+	 * `output retirement wait: 1/968 ... settled`, so the host's
+	 * sub-put release payloads were then forward-only-skipped and the
+	 * client read a stale buffer and failed; matmul's stage ordering
+	 * broke the same way). Only the release applies deliver completions;
+	 * this publish is the catch-up for entries the pump consumed WITHOUT
+	 * a decoded release, so it may run solely when nothing is
+	 * outstanding - the same equality the entry loop consumes to
+	 * (wrap-safe for the 1024-entry rings).
+	 */
+	if (ch->last_get != put)
+		return;
 	svc.counter_pub_calls++;
 	if (gsp_sema_dbg && !ch->engine_type &&
 	    svc.counter_pub_dbg < 96) {