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:15:52 +0000, [email protected] wrote: > Could these fixes be split out with Fixes: tags, so they can go to net and > stable separately from the reinitialization preparation? Agreed that these changes also fix existing behavior; they are not merely cosmetic preparation. The v8 messages describe that behavior explicitly. This revision retains the four-patch feature lineage and does not label a whole feature-preparation patch as a safe standalone stable backport. A minimal net/stable series needs separate extraction, a verified Fixes origin and validation on its target baseline. That separate backport work is deferred, not rejected, and no claim is made that older kernels are fixed. > Does this leak the retained hw_channel_context when the gdma_context > itself is freed? 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. > Say an EQ interrupt on another CPU has already loaded the slot here. Can > it then read freed memory and call through cq->cq.callback? A local RDMA > user can reach this by calling ibv_destroy_cq() on an armed CQ. This is a valid independent RDMA CQ concern, not dismissed because it is pre-existing. mana_ib_install_cq_cb() and mana_ib_remove_cq_cb() are byte-identical to the pinned baseline: the separate callback object is published without the required per-object protocol and freed before withdrawal/grace. The HWC series protects its own table/bundle lifetime; it does not establish a lifetime for every RDMA callback object. A fix belongs in the RDMA install/remove/destroy protocol and requires its own ordering and coexistence validation. No RDMA CQ lifetime fix is claimed here. > Then mana_gd_destroy_queue() frees the queue memory and calls > kfree(queue) without waiting for a grace period. Agreed that table lifetime and individual datapath CQ lifetime are different contracts. The baseline generic destroy path clears the slot and frees the CQ without an intervening grace period, and the IRQ reader does not restrict a device-supplied CQ ID to the delivering EQ. HWC's table withdrawal does not repair those earlier individual-CQ retirements. The independent queue-set work addresses Ethernet CQ publication/retirement; it is not stacked into this HWC series. Overlapping hunks must be reconciled while preserving both contracts, whichever series lands second. Regards, Wei
