Re: [PATCH net-next v2 0/7] net: mana: harden the HWC and add dynamic queue depth

From: Paolo Abeni

Date: Tue Jul 28 2026 - 07:00:54 EST


On 7/22/26 1:43 AM, Long Li wrote:
> This series hardens the MANA Hardware Channel (HWC) control-plane path
> and then builds on that to support a dynamic HWC queue depth.
>
> The HWC is the command channel the driver uses to talk to the device.
> Today it is created at a fixed depth of one outstanding request, and
> several of its lookup and teardown paths predate the RCU and DMA-lifetime
> rules they now need to follow. Raising the queue depth and allowing
> concurrent commands makes those latent races reachable, so the fixes come
> first and the feature builds on them.
>
> Patches 1-5 are fixes for pre-existing HWC bugs, each with a Fixes: tag:
>
> 1: cq_table was a plain pointer array freed with no grace period while
> the EQ interrupt handler dereferenced it; put it under RCU.
> 2: the HWC RQ and SQ were sized with each other's message size, so a
> response could overflow the RQ buffer and the RX slot stride was
> computed with the wrong size.
> 3: comp_buf was freed before the EQ was destroyed, so a late completion
> handler could touch freed memory.
> 4: the RX path consumed device-supplied lengths and indices without
> validation; validate them before use (this matters for confidential
> VMs, where the DMA buffer is shared with the host).
> 5: a failed mana_hwc_establish_channel() could leave live MST entries
> while the driver freed the queue buffers, and destroy_channel() freed
> the TXQ/RXQ before the EQ was quiesced; add a setup_active teardown
> gate and destroy the CQ first.

Fixes should go via the net tree. Targeting net-next to avoid waiting
the merge to post the dependant features is not a valid reason.

Also both sashikos agrees pcie_fpr() in patch 5 is not the correct
function to be used there.

Also please note the expectations WRT LLMs feedback, commit c82ff94592fb.

/P