From: sashiko-bot@kernel.org
To: "Yishai Hadas" <yishaih@nvidia.com>
Cc: linux-rdma@vger.kernel.org
Subject: Re: [PATCH V1 rdma-next 08/15] RDMA/mlx5: Fix mlx5_ib_dev_res_init() failure when XRC cap is absent
Date: Tue, 15 Sep 2026 14:24:44 +0000 [thread overview]
Message-ID: <20260915142444.D99A31F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260915140933.40580-9-yishaih@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] rdma/mlx5: missing mutex_destroy() on error path in mlx5_ib_dev_res_init()
--
commit c4290e2ba9444b4168574311394c1c28313c0387
Author: Yishai Hadas <yishaih@nvidia.com>
Subject: RDMA/mlx5: Fix mlx5_ib_dev_res_init() failure when XRC cap is absent
This commit makes XRC capabilities optional in the driver probe path. It
initializes the cq_lock and srq_lock unconditionally at the start of device
resource initialization and skips the xrcd allocation and placeholder SRQ
when XRC is absent.
> diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
> index 373ee1f42d4ad..8b8a0f26cf19f 100644
> --- a/drivers/infiniband/hw/mlx5/main.c
> +++ b/drivers/infiniband/hw/mlx5/main.c
[ ... ]
> @@ -3434,8 +3443,11 @@ static int mlx5_ib_dev_res_init(struct mlx5_ib_dev *dev)
> struct mlx5_ib_resources *devr = &dev->devr;
> int ret;
>
> + mutex_init(&devr->cq_lock);
> + mutex_init(&devr->srq_lock);
> +
> if (!MLX5_CAP_GEN(dev->mdev, xrc))
> - return -EOPNOTSUPP;
> + return 0;
>
> ret = mlx5_cmd_xrcd_alloc(dev->mdev, &devr->xrcdn0, 0);
> if (ret)
> @@ -3447,9 +3459,6 @@ static int mlx5_ib_dev_res_init(struct mlx5_ib_dev *dev)
> return ret;
> }
>
> - mutex_init(&devr->cq_lock);
> - mutex_init(&devr->srq_lock);
> -
> return 0;
> }
[Severity: Low]
Since cq_lock and srq_lock are now unconditionally initialized at the start
of mlx5_ib_dev_res_init(), do we need to call mutex_destroy() on the error
paths if mlx5_cmd_xrcd_alloc() fails?
If either xrcd allocation fails, the function returns directly without
cleaning up the initialized mutexes. Could this missing cleanup break API
symmetry and trigger warnings in debug builds when the device memory is
subsequently freed?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260915140933.40580-1-yishaih@nvidia.com?part=8
next prev parent reply other threads:[~2026-09-15 14:24 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 14:09 [PATCH V1 rdma-next 00/15] DMA direction and mlx5 driver correctness fixes Yishai Hadas
2026-09-15 14:09 ` [PATCH V1 rdma-next 01/15] RDMA/erdma: Pin CQ buffer writable to match device DMA write access Yishai Hadas
2026-09-15 14:22 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 02/15] RDMA/hns: " Yishai Hadas
2026-09-15 14:20 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 03/15] RDMA/vmw_pvrdma: Pin QP and SRQ rings " Yishai Hadas
2026-09-15 14:21 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 04/15] RDMA/umem: Reuse ib_umem_get_cq_buf_or_va() for VA-only CQ pinning Yishai Hadas
2026-09-15 14:21 ` sashiko-bot
2026-09-20 12:24 ` Leon Romanovsky
2026-09-22 7:25 ` Yishai Hadas
2026-09-15 14:09 ` [PATCH V1 rdma-next 05/15] RDMA/umem: Support an explicit DMA direction other than DMA_BIDIRECTIONAL Yishai Hadas
2026-09-15 14:21 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 06/15] RDMA/umem: Map CQ buffers DMA_FROM_DEVICE Yishai Hadas
2026-09-15 14:25 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 07/15] RDMA/umem: Derive DMA direction from IB access flags Yishai Hadas
2026-09-15 14:28 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 08/15] RDMA/mlx5: Fix mlx5_ib_dev_res_init() failure when XRC cap is absent Yishai Hadas
2026-09-15 14:24 ` sashiko-bot [this message]
2026-09-15 14:09 ` [PATCH V1 rdma-next 09/15] RDMA/mlx5: Put resource reference in mlx5_ib_wq_event() Yishai Hadas
2026-09-15 14:25 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 10/15] RDMA/mlx5: Set WQ event handler before firmware RQ insertion Yishai Hadas
2026-09-15 14:30 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 11/15] RDMA/mlx5: Set SRQ event handler before xarray insertion Yishai Hadas
2026-09-15 14:36 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 12/15] RDMA/mlx5: Set RQ event handler for raw-packet QP Yishai Hadas
2026-09-15 14:32 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 13/15] RDMA/mlx5: Set QP event handler before firmware QPC insertion Yishai Hadas
2026-09-15 14:35 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 14/15] RDMA/mlx5: Initialize QP/RQ/SQ resource refcount before publishing it Yishai Hadas
2026-09-15 14:29 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 15/15] RDMA/mlx5: Fix signed integer overflow in EQE qp_srq type shift Yishai Hadas
2026-09-15 14:31 ` sashiko-bot
2026-09-28 12:17 ` [PATCH V1 rdma-next 00/15] DMA direction and mlx5 driver correctness fixes Leon Romanovsky
2026-09-28 12:19 ` Leon Romanovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260915142444.D99A31F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=yishaih@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox