Thanks for the review. I have prepared a four-patch v8 based on net-next commit 05b5019b01fb, with the following dispositions.
On Wed, 14 Oct 2026 08:06:25 +0000, [email protected] wrote: > [Severity: High] > During HWC teardown, the dedicated HWC EQ is fenced (which includes a > synchronize_rcu() wait), and then the HWC CQ is destroyed. The CQ memory > is freed without a subsequent RCU grace period. Can a concurrently running > IRQ handler for a different active EQ (like an ENET EQ) read the CQ pointer > from cq_table just before it is cleared, and dereference it after it is freed > here? > Addressed in v8 patch 1. The CQ table is withdrawn and existing IRQ-side RCU readers are drained BEFORE the HWC CQ, completion buffer and queue bundle are freed. Fencing only the dedicated HWC EQ is not used as proof that another EQ cannot hold this CQ. The ordering is in the owning first patch, not a later repair. This is HWC table/bundle protection, not a claim to repair every individual Ethernet or RDMA CQ lifetime > [Severity: Low] > For normal networking queues, this happens before the EQ is fenced, so the > EQ handler may concurrently execute the READ_ONCE(cq_table[cq_id]). > Should this writer be updated to WRITE_ONCE() to prevent a formal data > race? Fixed in v8 patch 1: CQ-slot clearing uses WRITE_ONCE to pair with the annotated reader. This annotation does not by itself supply a grace period or solve individual CQ publication/lifetime. > [Severity: Medium] > During driver unload (mana_gd_remove), vfree(gc) is eventually called, which > destroys the parent gdma_context and permanently leaks the retained > gc->hwc.driver_data (hwc) and gc->cq_table on this error path. > Fixed in v8 patch 1. A retained channel remains available for retry while its gdma_context survives. When a PCI or CDX path finally discards that context, a common final-disposal helper now releases software-only wrappers, caller state, the bitmap and CQ table after the required CPU users are quiesced. Coherent allocations are deliberately NOT freed without an acknowledged ownership transfer. This fixes the additional software leak; it does not claim that an unresponsive PF can be made to release DMA memory. Regards, Wei
