Re: [PATCH net-next v1 0/4] net/mlx5: Don't free CQs whose destroy failed

[Leon Romanovsky]

On Fri, Oct 16, 2026 at 12:57:45AM -0400, Yuho Choi wrote:
> mlx5_core_destroy_cq() can fail

No, it should not fail. If it does, the firmware is completely broken
or some other catastrophic bug.

> nd when it does the CQ may still exist in firmware with access to its buffer and doorbell record. It
> also returns early in that case, without waiting for EQ handlers that
> may already hold a reference to the CQ. The four helpers in this series
> ignore that error and free the CQ buffer anyway, while their teardown
> paths also free the object that embeds the struct mlx5_core_cq.
> 
> Keep the buffer and the object that embeds the CQ when DESTROY_CQ
> fails, as the regular mlx5_ib CQ destroy path does. The HWS send ring
> CQs are polled and never armed, so the HWS patch keeps only their
> buffer rather than passing the error up through the queue open and
> close paths.
> 
> The issues were found with a static analysis tool from ongoing, not yet
> published research, and confirmed by code inspection. None of them was
> reproduced, so this targets net-next; I can resend for net if you
> prefer.

Please drop this series. The flow is impossible in current HW implementation.

Thanks