On Thu, Oct 08, 2026 at 12:54:01PM +0000, [email protected] wrote: > Can this dereference of cq race with mana_gd_destroy_queue() and cause a > use-after-free?
Thanks for the review. I agree that the Ethernet CQ lifetime gap described here needs to be fixed. However, it is already present on the base of this series, c66d93e68728, rather than introduced by this patch. On that base, mana_gd_destroy_cq() clears the CQ table entry without waiting for existing readers, and mana_gd_destroy_queue() subsequently frees the queue. Both functions and the Ethernet CQ-before-EQ teardown order are unchanged by this series. The original completion handler also obtained the CQ pointer and dereferenced it without a corresponding reclamation grace period. The reader changes here serve a different purpose: the acquire-load of gc->cq_table pairs with HWC's release-publication of the initialized table and its bound, while the NULL checks handle an unpublished table or entry. They do not provide lifetime protection for an Ethernet CQ that another CPU has already obtained from the table. For HWC specifically, this patch destroys its dedicated EQ before freeing the CQ and callback state. EQ deregistration removes the EQ from the IRQ dispatch list and calls synchronize_rcu(), draining the existing IRQ-side readers before the HWC CQ is released. This does not protect the separate Ethernet CQ teardown path described in the report. The reported CQ-destruction path is fixed in an independent MANA queue-set replacement series that I plan to post shortly. That change unpublishes the exact CQ pointer and waits for existing IRQ-side RCU readers before the CQ is freed. It adds teardown-side synchronization without adding per-completion reference counting. I am keeping that pre-existing-bug fix in the independent series rather than expanding the scope of this HWC concurrency and queue-depth series. Thanks, Wei
