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

[Tariq Toukan]

On 18/10/2026 15:55, Leon Romanovsky wrote:
> 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

pw-bot: cr