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

[Tariq Toukan <tariqt@nvidia.com>]

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