RE: [EXTERNAL] Re: [PATCH net-next v7 3/4] net: mana: support concurrent HWC requests

[Wei Hu]

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, netdev-bot+sashiko@xxxxxxxxxx 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