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
