fix(rdma): cco/shmem indicies wraparound (#626)

[QizhouZhang97]

postIdx / dbTouchIdx / doneIdx wrap at 2^32, so only their order matters. Flow
control mixed uint32 and uint64, underflowing into a forever-spin on an empty SQ;
fetch_max freezes the counter at the wrap; ionic's 24-bit MSN stored raw broke the
in-flight count past 2^24. Fixed all three, plus a boundary test.

[jhchouuu]

great work!

Could we also check if this issue exists in mlx5 and bnxt?

[jhchouuu]

Data point from BNXT, in case it helps target this: we hit exactly the bug this PR fixes, and your BNXT hunk resolves it — but the trigger we saw is not a 2^32 wrap, so the rationale and the new test may be worth widening.

What we saw

2 nodes x 8 MI308X (gfx942), bnxt_re, EP internode dispatch_ll over CCO/GDA. Roughly 1 run in 3 hung mid-test. Every time the signature was identical: of 768 waves, 767 exit and one spins forever in quietUntil<BNXT>.

Live state off that wave under rocgdb:

postIdx    = 103
dbTouchIdx = 103
doneIdx    = 0xfffff067      <- 103 - 4096, frozen across re-reads
sqWqeNum   = 4096
targetIdx  = 103

postIdx == dbTouchIdx == targetIdx means everything was posted and doorbelled — nothing was outstanding on the wire. The counter was simply poisoned, exactly as this PR describes: __hip_atomic_fetch_max on uint32_t compiles to global_atomic_umax (confirmed in the ISA), so the wrapped value is the unsigned maximum, wins the max and pins doneIdx, while done()'s (int32_t)(doneIdx - targetIdx) >= 0 reads it as 4096 behind.

The trigger is not the 2^32 wrap

ringDoorbellOrdered rings the doorbell before publishing dbTouchIdx (there is a __threadfence_system() and, in the multi-lane case, a whole ringDoorbellWalk in between), so a collapsed-CQ poller can legitimately observe a completion ahead of dbTouchIdx:

dbTouch reads 102 while the CQE already reports con_indx = 103
completed = (102 & ~4095) | 103 = 103
103 > 102  ->  completed = 103 - 4096 = 0xfffff067

which reproduces the observed value exactly. So this fires within the first sqWqeNum (4096) WQEs of a QP's life, not after 2^32. Two consequences:

• tests/cpp/cco/test_gda_wraparound.cpp only covers the 2^32 gate, so the case that actually bit us stays uncovered.
• As written, the rationale invites a reviewer to wave the BNXT hunk off with "we never reach 2^32" — it is the one hunk that fixes a first-4096-WQE hang.

It might also be worth noting that this PR suppresses the bad publication but leaves the computation: if (completed > dbTouch) completed -= wq->sqWqeNum; still discards a valid completion whenever the race fires. That is harmless on BNXT only because PollSingleCqe is level-triggered for cqeNum == 1 — it has no phase check, so it re-reads con_indx and the next iteration recovers. Worth a comment so nobody later "fixes" that poll into a one-shot consume.

Validation

30-round --cmd test, v2_ll, 128 tokens, 16 ranks, JIT cache cleared between variants:

variant	hangs
this PR's two header hunks	0 / 12
unpatched	2 / 4 (32% over 19 historical runs)

We had independently written the same signed-ordered fix for the BNXT line before finding this PR, and dropped it in favour of yours. The hunks apply cleanly onto #625 and do not touch flushAsyncImpl, so the two are complementary.

---

Separately, and not reproduced — we have no ionic/PSD hardware, this is from reading the code only: in the PSD non-CCQE branch the CQE is consumed (cq->cq_consumer = myCqPos + 1) before the new dbTouchIdx cap decides whether to accept it. If the cap rejects, that completion looks unrecoverable there, unlike BNXT where the CQE can be re-read. Might be worth a second look.