Re: [PATCH net-next v6 1/4] net: mana: prepare HWC ownership for safe reinitialization

[Wei Hu <weh@linux.microsoft.com>]

On Thu, Oct 08, 2026 at 12:54:01PM +0000, sashiko-bot@kernel.org 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