Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] A spurious, duplicate, or maliciously early hardware response can prematurely free the message slot before the sender takes its reference, leading to a refcount use-after-free/saturation and data corruption. --
--- Patch [6]: [PATCH net v3 6/6] net: mana: fix stale HWC response after command timeout --- commit 374238ca2c81aa20a65060ecc749dc0a454b16f8 Author: Long Li <[email protected]> net: mana: fix stale HWC response after command timeout This commit introduces a refcounted spinlock mechanism for caller contexts to prevent stale HWC responses from corrupting output buffers or completing the wrong command after a timeout. > diff --git a/drivers/net/ethernet/microsoft/mana/hw_channel.c > b/drivers/net/ethernet/microsoft/mana/hw_channel.c > index 1603968d7989a..d92032b466af2 100644 > --- a/drivers/net/ethernet/microsoft/mana/hw_channel.c > +++ b/drivers/net/ethernet/microsoft/mana/hw_channel.c [ ... ] > @@ -1034,8 +1104,14 @@ int mana_hwc_send_request(struct hw_channel_context > *hwc, u32 req_len, > dest_vrcq = hwc->pf_dest_vrcq_id; > } > > + /* Take handle_resp's ref before posting — hardware can respond > + * immediately after the doorbell ring. > + */ > + refcount_inc(&ctx->refcnt); [Severity: High] Could a spurious or duplicate hardware response arrive before this reference is incremented? Looking at mana_hwc_get_msg_index(), the slot is marked in the inflight bitmap and the refcount is initialized to 1: mana_hwc_get_msg_index() bitmap_set(r->map, index, 1); refcount_set(&ctx->refcnt, 1); ctx->responded = false; Since the slot is immediately visible to the CQ interrupt handler upon being added to the bitmap, if an unexpected response arrives before the sender reaches this refcount_inc() call, mana_hwc_handle_resp() could process it. It would see ctx->responded is false, set it to true, and call hwc_ctx_put(). Because the sender hasn't taken its additional reference yet, hwc_ctx_put() would drop the only reference and free the slot prematurely. When the sender finally reaches this refcount_inc(), it would increment a zero-refcount, triggering a warning for saturation and permanently leaking the HWC slot. Should the refcount be initialized to 2 in mana_hwc_get_msg_index() to account for both the sender and the response, rather than incrementing it later during the request setup? -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=6
