Thanks for the review. I have prepared a four-patch v8 based on net-next commit 05b5019b01fb, with the following dispositions.
On Wed, 14 Oct 2026 08:15:56 +0000, [email protected] wrote: > Is -EBUSY the right return value when the slot is held by a request that > timed out? Fixed in v8 patch 3. Outstanding abandoned responses are counted separately from healthy admission pressure. If admission expires while such responses still hold slots, the caller receives -ETIMEDOUT so the existing statistics/recovery path remains reachable; ordinary saturation still returns -EBUSY. A late response or teardown retires that state exactly once with the response reference. Device status is not overloaded as a flag. > Would it work to initialize the slot while holding ctx->lock nested inside > r->lock, which matches the existing r->lock then ctx->lock order? Or to > clear the bitmap bit while holding ctx->lock? Fixed in v8, starting with the per-slot initialization in patch 2 and retained in patch 3. Initialization now takes ctx->lock while holding the resource lock, matching the response path's lock order, and publishes the bitmap bit last. Returning a permit does not let a new initializer race an older callback still holding ctx->lock. This fixes that lifetime interleaving; it does not invent a wire generation field or claim to distinguish every stale duplicate after a completed message ID has been reused. > Larger depths only arrive with the next patch in the series, "net: mana: > add dynamic HWC queue depth with reinit path". Could the message say so? Clarified in the v8 patch-3 message: bootstrap remains depth one at this intermediate commit; the following patch negotiates and allocates larger queues. Patch 3 supplies the concurrency-capable ownership/admission machinery, not a claim that multiple firmware requests are already outstanding with a depth-one channel. > Does this case need a narrower unwind? It can only happen if channel > creation runs concurrently without serialization, which the normal > lifecycle doesn't do. The reported WARN-only failure path is not claimed to recover overlapping channel creation on one gdma_context. This series supports concurrent requests, not concurrent device setup/teardown. Before the publication check, setup has already used GC-wide SMC, IRQ and CQ-table state, so merely changing cleanup at that check would not preserve an independently created winner. A complete solution needs device-lifecycle serialization from setup entry. I have left this as an explicit lifecycle follow-up rather than add a partial concurrency/reset policy in this series. No PM/service/remove overlap qualification or fix is claimed. > Once a late response frees the slot, later commands are posted to the > firmware and abandoned after about one jiffy, while the firmware may still > be executing them. Callers like mana_gd_create_mana_wq_cq() then free the > DMA memory those commands refer to. Agreed that the existing one-millisecond fail-fast policy does not establish DMA-command completion. That reduction and callers which release data-queue memory after failed control requests already exist in the baseline. V8 preserves the runtime policy while retaining timed-out HWC slots until their responses retire or teardown cancels them, and restores the existing recovery errno. Fixing the wider data-queue/DMA failure policy requires an independently established device-quiescence contract. It is not repaired or represented as safe by this HWC series. > With a depth of 1, wouldn't a single out-of-range msg_id from the device > leave the RQ with no posted buffers for the rest of the channel's life? > With the new -EBUSY behaviour above, that starved channel would also never > trigger recovery. Confirmed as a separate baseline issue: the RX handler rejects an invalid msg_id after locating rx_req but returns without reposting that request. That function is unchanged by this series. It should be addressed with explicit malformed-response handling and the RX ownership/repost contract, not hidden inside the concurrency change. V8 fixes the separate admission/recovery classification, but does not claim that malformed responses cannot starve this RQ. Regards, Wei pw-bot: cr
