[PATCH rdma] RDMA/mlx5: Cancel software CQ notifications before teardown

[PATCH rdma] RDMA/mlx5: Cancel software CQ notifications before teardown

[Prathamesh Deshpande]

GSI completions queue notify_work to invoke the CQ completion handler.
CQ destruction drains hardware events and core polling, but does not
cancel this software notifier. Queued or running work can therefore
access a freed CQ, or restart polling after ib_free_cq() has drained it.

Cancel notify_work in the pre-destroy callback, before core polling is
stopped and CQ memory is released. Skip user CQs, which do not initialize
this work item.

Fixes: 25361e02c448 ("IB/mlx5: Generate completions in software")
Signed-off-by: Prathamesh Deshpande <prathameshdeshpande7@gmail.com>
---
 drivers/infiniband/hw/mlx5/cq.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/infiniband/hw/mlx5/cq.c b/drivers/infiniband/hw/mlx5/cq.c
index 49b4bf148a4a..1653b2747f5f 100644
--- a/drivers/infiniband/hw/mlx5/cq.c
+++ b/drivers/infiniband/hw/mlx5/cq.c
@@ -1117,6 +1117,9 @@ int mlx5_ib_pre_destroy_cq(struct ib_cq *cq)
 	struct mlx5_ib_dev *dev = to_mdev(cq->device);
 	struct mlx5_ib_cq *mcq = to_mcq(cq);
 
+	if (!cq->uobject)
+		cancel_work_sync(&mcq->notify_work);
+
 	return mlx5_core_destroy_cq(dev->mdev, &mcq->mcq);
 }
 
-- 
2.43.0

Re: [PATCH rdma] RDMA/mlx5: Cancel software CQ notifications before teardown

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] rdma/mlx5: missing wc_list drain in mlx5_ib_pre_destroy_cq() causes leak
--

commit bb2bb35d84abe8b8d9f71ac658dfcd1b34acddcb
Author: Prathamesh Deshpande <prathameshdeshpande7@gmail.com>

RDMA/mlx5: Cancel software CQ notifications before teardown

This commit cancels notify_work in the pre-destroy callback to prevent queued
or running work from accessing a freed CQ or restarting polling after the CQ
is drained. User CQs are skipped because they do not initialize this work
item.

> diff --git a/drivers/infiniband/hw/mlx5/cq.c b/drivers/infiniband/hw/mlx5/cq.c
> index 072b77a2c8a6c..7495e20c3dec9 100644
> --- a/drivers/infiniband/hw/mlx5/cq.c
> +++ b/drivers/infiniband/hw/mlx5/cq.c
> @@ -1117,6 +1117,9 @@ int mlx5_ib_pre_destroy_cq(struct ib_cq *cq)
>  	struct mlx5_ib_dev *dev = to_mdev(cq->device);
>  	struct mlx5_ib_cq *mcq = to_mcq(cq);
>  
> +	if (!cq->uobject)
> +		cancel_work_sync(&mcq->notify_work);
> +

[Severity: Medium]
Does this code cause a memory leak regression by leaving dynamically allocated
elements in mcq->wc_list undrained?

When mlx5_ib_generate_wc() generates software completions, it dynamically
allocates memory for them and queues them to the wc_list:

mlx5_ib_generate_wc() {
	...
	soft_wc = kmalloc_obj(*soft_wc, GFP_ATOMIC);
	...
	list_add_tail(&soft_wc->list, &cq->wc_list);
	...
}

If the CQ is destroyed before these completions are polled,
mlx5_ib_pre_destroy_cq() correctly stops the workqueue to prevent
use-after-free, but it fails to drain mcq->wc_list.

Since the work queue is no longer running to consume these elements, they
will be leaked when the CQ is freed.

>  	return mlx5_core_destroy_cq(dev->mdev, &mcq->mcq);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261008141209.6923-1-prathameshdeshpande7@gmail.com?part=1