Re: [PATCH net-next v7 2/4] net: mana: give each HWC message slot its own completion state

[netdev-bot+sashiko@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 1

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] At this commit, one genuine HWC timeout sets the channel-wide
  latch hwc->hwc_timed_out, in mana_hwc_put_msg_index(..., true) called…
- [Low] This patch fixes real bugs that exist in the baseline driver,
  including a memory-safety bug, but carries no Fixes: tag and no stable…

--

net: mana: give each HWC message slot its own completion state

This commit adds a per-slot spinlock to hwc_caller_ctx. The lock protects
output_buf, error and status_code. The commit also reinitializes the
completion and result state when a slot is acquired, and adds a
channel-wide hwc_timed_out latch that rejects new requests after a genuine
timeout. Status handling and request cleanup are split into helpers.

Link: https://lore.kernel.org/r/20260908035201.402424-3-longli@microsoft.com
Link: https://lore.kernel.org/r/20260908035201.402424-4-longli@microsoft.com

> diff --git a/drivers/net/ethernet/microsoft/mana/hw_channel.c b/drivers/net/ethernet/microsoft/mana/hw_channel.c
> index b1d972968f0d7..89b6e30863dae 100644
> --- a/drivers/net/ethernet/microsoft/mana/hw_channel.c
> +++ b/drivers/net/ethernet/microsoft/mana/hw_channel.c

[ ... ]

> @@ -16,9 +17,22 @@ static int mana_hwc_get_msg_index(struct hw_channel_context *hwc, u16 *msg_id)
>  
>  	spin_lock_irqsave(&r->lock, flags);
>  
> +	if (hwc->hwc_timed_out) {
> +		spin_unlock_irqrestore(&r->lock, flags);
> +		up(&hwc->sema);
> +		return -ETIMEDOUT;
> +	}

[Severity: Medium]
After one genuine timeout, mana_hwc_send_request() calls
mana_hwc_finish_request(hwc, ctx, msg_id, true). That sets
hwc->hwc_timed_out in mana_hwc_put_msg_index(). Nothing clears the flag
until the hwc is freed and mana_hwc_create_channel() allocates a new one.

After that point, does every mana_hwc_get_msg_index() call return
-ETIMEDOUT without posting anything to the SQ? That would include teardown
commands.

For example, mana_gd_destroy_queue() ignores the result of the destroy
command and frees the host memory anyway:

drivers/net/ethernet/microsoft/mana/gdma_main.c:mana_gd_destroy_queue() {
    ...
	mana_gd_destroy_dma_region(gc, gmi->dma_region_handle);
	mana_gd_free_memory(gmi);
	kfree(queue);
}

If the device was only slow and not dead, could it keep a DMA region
mapping that points at freed host pages?

mana_serv_reset() in gdma_pci.c does this:

	/* HWC is not responding in this case, so don't wait */
	hwc->hwc_timeout = 0;

With a zero timeout, the first suspend command now latches the channel,
so the rest of the suspend-time destroy commands are never posted. Before
this patch they were posted.

The firmware HWC_DATA_CFG_HWC_TIMEOUT update in
mana_hwc_init_event_handler() changes hwc_timeout but cannot clear the
latch. Runtime timeout users such as mana_gf_stats_work_handler() will
also see later commands fail without being sent until the reset runs.

The next patch in the series, "net: mana: support concurrent HWC
requests", removes hwc_timed_out. It replaces the latch with per-slot
quarantine, which a late response or teardown releases. So this only
affects this intermediate commit, either during bisection or if this
patch is backported alone.

Could this commit avoid the channel-wide latch so that every commit in the
series is bisect-safe?

> +
>  	index = find_first_zero_bit(hwc->inflight_msg_res.map,
>  				    hwc->inflight_msg_res.size);
>  
> +	ctx = &hwc->caller_ctx[index];
> +	reinit_completion(&ctx->comp_event);
> +	ctx->output_buf = NULL;
> +	ctx->output_buflen = 0;
> +	ctx->error = -EINPROGRESS;
> +	ctx->status_code = 0;

[Severity: Low]
This isn't a bug in the new code. These changes, together with the
output_buf handling under ctx->lock, fix problems that exist in the
baseline driver, but the commit has no Fixes: tag and no Cc: stable.

In the baseline, the bootstrap channel has depth one, so every request
uses msg_id 0. Three problems follow from that.

First, mana_hwc_get_msg_index() never called reinit_completion(). A late
complete() for a request that had already timed out left comp_event done.
The next wait_for_completion_timeout() then returned at once, with stale
error and status_code values and a response buffer that was never filled.

Second, mana_hwc_handle_resp() only checked test_bit(msg_id) before
memcpy(ctx->output_buf, ...). There is a window between bitmap_set() in
mana_hwc_get_msg_index() and this assignment in mana_hwc_send_request():

	ctx->output_buf = resp;

A stale response arriving in that window could pass the check and copy
into the previous caller's output_buf. That buffer is often on the stack,
such as the resp in mana_gd_query_hwc_timeout(), and that function has
already returned.

Third, a late response arriving after the next request had set its bit
and output_buf would be accepted as the answer to that request.

The commit message does say "A late response therefore cannot copy through
a pointer to caller storage whose lifetime has ended". Without a Fixes:
tag, though, stable trees won't pick this up. A plain backport of this
patch would also carry the hwc_timed_out latch that the next patch
removes.

Would it make sense to send a self-contained fix for these, with a Fixes:
tag, to net separately?

> +
>  	bitmap_set(hwc->inflight_msg_res.map, index, 1);
>  
>  	spin_unlock_irqrestore(&r->lock, flags);

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/cover.1791561995.git.weh%40linux.microsoft.com