[PATCH 1/2] RDMA/ionic: Fix XArray initialization to use XArray flags

[PATCH 1/2] RDMA/ionic: Fix XArray initialization to use XArray flags

[Abhijit Gangurde]

xa_init_flags() takes XArray flags (XA_FLAGS_*), not gfp flags, even
though the parameter is typed gfp_t. Passing GFP_ATOMIC leaves both
lock-type bits clear, so xa_lock_type() resolves to XA_LOCK_NORMAL for
qp_tbl and cq_tbl.

Both tables are used with the IRQ-safe accessors: xa_store_irq() with
GFP_KERNEL from process context, and xa_lock_irqsave() from the event
queue path. When a store needs to grow the tree, __xas_nomem() drops
the lock using the recorded lock type before allocating:

	if (gfpflags_allow_blocking(gfp)) {
		xas_unlock_type(xas, lock_type);
		xas->xa_alloc = kmem_cache_alloc_lru(...);
		xas_lock_type(xas, lock_type);
	}

With XA_LOCK_NORMAL that is a plain spin_unlock(), so the sleeping
GFP_KERNEL allocation runs with interrupts still disabled by
xa_store_irq(), and lockdep annotates the lock with the wrong class.

GFP_ATOMIC also happens to set __GFP_HIGH (0x20), which collides with
XA_FLAGS_ACCOUNT (32U) and silently enables memcg accounting of the
XArray nodes.

Use XA_FLAGS_LOCK_IRQ so the lock type matches how the tables are
actually accessed.

Fixes: e8521822c733 ("RDMA/ionic: Register device ops for control path")
Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com>
---
 drivers/infiniband/hw/ionic/ionic_ibdev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/hw/ionic/ionic_ibdev.c b/drivers/infiniband/hw/ionic/ionic_ibdev.c
index cba7809ec3d9..fa79732c2f7d 100644
--- a/drivers/infiniband/hw/ionic/ionic_ibdev.c
+++ b/drivers/infiniband/hw/ionic/ionic_ibdev.c
@@ -320,8 +320,8 @@ static struct ionic_ibdev *ionic_create_ibdev(struct ionic_aux_dev *ionic_adev)
 
 	ionic_fill_lif_cfg(ionic_adev->lif, &dev->lif_cfg);
 
-	xa_init_flags(&dev->qp_tbl, GFP_ATOMIC);
-	xa_init_flags(&dev->cq_tbl, GFP_ATOMIC);
+	xa_init_flags(&dev->qp_tbl, XA_FLAGS_LOCK_IRQ);
+	xa_init_flags(&dev->cq_tbl, XA_FLAGS_LOCK_IRQ);
 
 	ionic_init_resids(dev);
 
-- 
2.43.0

[PATCH 2/2] RDMA/ionic: Fix double removal of CMB mmap entries in create QP error path

[Abhijit Gangurde]

The error unwind in ionic_create_qp() removes the SQ and RQ CMB mmap
entries explicitly, and then falls through to ionic_qp_rq_destroy() and
ionic_qp_sq_destroy(), whose ionic_qp_{rq,sq}_destroy_cmb() helpers
remove the very same entries a second time.

Drop the explicit removals and leave ionic_qp_{rq,sq}_destroy_cmb() as
the single owner on the ionic_destroy_qp() path.

Fixes: e8521822c733 ("RDMA/ionic: Register device ops for control path")
Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com>
---
 drivers/infiniband/hw/ionic/ionic_controlpath.c | 16 +++++-----------
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/infiniband/hw/ionic/ionic_controlpath.c b/drivers/infiniband/hw/ionic/ionic_controlpath.c
index 37f71fb43811..190128290f02 100644
--- a/drivers/infiniband/hw/ionic/ionic_controlpath.c
+++ b/drivers/infiniband/hw/ionic/ionic_controlpath.c
@@ -2350,7 +2350,7 @@ int ionic_create_qp(struct ib_qp *ibqp, struct ib_qp_init_attr *attr,
 						    &resp.sq_cmb_offset);
 			if (!qp->mmap_sq_cmb) {
 				rc = -ENOMEM;
-				goto err_mmap_sq;
+				goto err_qp_cmd;
 			}
 
 			resp.sq_cmb = qp->sq_cmb;
@@ -2387,7 +2387,7 @@ int ionic_create_qp(struct ib_qp *ibqp, struct ib_qp_init_attr *attr,
 						    &resp.rq_cmb_offset);
 			if (!qp->mmap_rq_cmb) {
 				rc = -ENOMEM;
-				goto err_mmap_rq;
+				goto err_qp_cmd;
 			}
 
 			resp.rq_cmb = qp->rq_cmb;
@@ -2395,7 +2395,7 @@ int ionic_create_qp(struct ib_qp *ibqp, struct ib_qp_init_attr *attr,
 
 		rc = ib_respond_udata(udata, resp);
 		if (rc)
-			goto err_resp;
+			goto err_qp_cmd;
 	}
 
 	ionic_pgtbl_unbuf(dev, &rq_buf);
@@ -2413,7 +2413,7 @@ int ionic_create_qp(struct ib_qp *ibqp, struct ib_qp_init_attr *attr,
 		else
 			rc = xa_err(entry);
 
-		goto err_resp;
+		goto err_qp_cmd;
 	}
 
 	if (qp->has_sq) {
@@ -2444,13 +2444,7 @@ int ionic_create_qp(struct ib_qp *ibqp, struct ib_qp_init_attr *attr,
 
 	return 0;
 
-err_resp:
-	if (udata && (qp->rq_cmb & IONIC_CMB_ENABLE))
-		rdma_user_mmap_entry_remove(qp->mmap_rq_cmb);
-err_mmap_rq:
-	if (udata && (qp->sq_cmb & IONIC_CMB_ENABLE))
-		rdma_user_mmap_entry_remove(qp->mmap_sq_cmb);
-err_mmap_sq:
+err_qp_cmd:
 	ionic_destroy_qp_cmd(dev, qp->qpid);
 err_cmd:
 	ionic_pgtbl_unbuf(dev, &rq_buf);
-- 
2.43.0

Re: [PATCH 2/2] RDMA/ionic: Fix double removal of CMB mmap entries in create QP error path

[sashiko-bot]

> The error unwind in ionic_create_qp() removes the SQ and RQ CMB mmap
> entries explicitly, and then falls through to ionic_qp_rq_destroy() and
> ionic_qp_sq_destroy(), whose ionic_qp_{rq,sq}_destroy_cmb() helpers
> remove the very same entries a second time.
> 
> Drop the explicit removals and leave ionic_qp_{rq,sq}_destroy_cmb() as
> the single owner on the ionic_destroy_qp() path.
> 
> Fixes: e8521822c733 ("RDMA/ionic: Register device ops for control path")
> Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260925093638.3032149-1-abhijit.gangurde@amd.com?part=2

Re: [PATCH 1/2] RDMA/ionic: Fix XArray initialization to use XArray flags

[sashiko-bot]

> xa_init_flags() takes XArray flags (XA_FLAGS_*), not gfp flags, even
> though the parameter is typed gfp_t. Passing GFP_ATOMIC leaves both
> lock-type bits clear, so xa_lock_type() resolves to XA_LOCK_NORMAL for
> qp_tbl and cq_tbl.
> 
> Both tables are used with the IRQ-safe accessors: xa_store_irq() with
> GFP_KERNEL from process context, and xa_lock_irqsave() from the event
> queue path. When a store needs to grow the tree, __xas_nomem() drops
> the lock using the recorded lock type before allocating:
> 
> 	if (gfpflags_allow_blocking(gfp)) {
> 		xas_unlock_type(xas, lock_type);
> 		xas->xa_alloc = kmem_cache_alloc_lru(...);
> 		xas_lock_type(xas, lock_type);
> 	}
> 
> With XA_LOCK_NORMAL that is a plain spin_unlock(), so the sleeping
> GFP_KERNEL allocation runs with interrupts still disabled by
> xa_store_irq(), and lockdep annotates the lock with the wrong class.
> 
> GFP_ATOMIC also happens to set __GFP_HIGH (0x20), which collides with
> XA_FLAGS_ACCOUNT (32U) and silently enables memcg accounting of the
> XArray nodes.
> 
> Use XA_FLAGS_LOCK_IRQ so the lock type matches how the tables are
> actually accessed.
> 
> Fixes: e8521822c733 ("RDMA/ionic: Register device ops for control path")
> Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260925093638.3032149-1-abhijit.gangurde@amd.com?part=1

Re: [PATCH 1/2] RDMA/ionic: Fix XArray initialization to use XArray flags

[Leon Romanovsky]

On Fri, 25 Sep 2026 15:06:37 +0530, Abhijit Gangurde wrote:
> xa_init_flags() takes XArray flags (XA_FLAGS_*), not gfp flags, even
> though the parameter is typed gfp_t. Passing GFP_ATOMIC leaves both
> lock-type bits clear, so xa_lock_type() resolves to XA_LOCK_NORMAL for
> qp_tbl and cq_tbl.
> 
> Both tables are used with the IRQ-safe accessors: xa_store_irq() with
> GFP_KERNEL from process context, and xa_lock_irqsave() from the event
> queue path. When a store needs to grow the tree, __xas_nomem() drops
> the lock using the recorded lock type before allocating:
> 
> [...]

Applied, thanks!

[1/2] RDMA/ionic: Fix XArray initialization to use XArray flags
      https://git.kernel.org/rdma/rdma/c/2eca9c14e66a1f
[2/2] RDMA/ionic: Fix double removal of CMB mmap entries in create QP error path
      https://git.kernel.org/rdma/rdma/c/485effd117d031

Best regards,
-- 
Leon Romanovsky <leon@kernel.org>