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

[Paolo Abeni <pabeni@redhat.com>]

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