* [PATCH for-next] RDMA/ionic: Fix GSI QP ID release
@ 2026-10-21 16:16 Håkon Bugge
2026-10-21 16:29 ` sashiko-bot
0 siblings, 1 reply; 2+ messages in thread
From: Håkon Bugge @ 2026-10-21 16:16 UTC (permalink / raw)
To: Abhijit Gangurde, Allen Hubbe, Jason Gunthorpe, Leon Romanovsky,
Andrew Boyer
Cc: stable, Keith Lucas, Håkon Bugge, linux-rdma, linux-kernel
QPID allocation differs between ordinary QPs and GSI QPs. If GSI QP
creation fails after allocating its QPID, or is destroyed, we see in
the log (trimmed for brevity):
kernel: ida_free called for id=32 which is not allocated.
kernel: WARNING: CPU: 47 PID: 6673 at lib/idr.c:527 ida_free+0xde/0x140
kernel: CPU: 47 UID: 0 PID: 6673 Comm: modprobe Not tainted 6.12.0+ #18
kernel: RIP: 0010:ida_free+0xde/0x140
kernel: Call Trace:
kernel: <TASK>
kernel: ionic_create_qp+0x4f5/0xbe0 [ionic_rdma]
kernel: create_qp+0x19a/0x290 [ib_core]
kernel: ib_create_qp_kernel+0x3a/0xe0 [ib_core]
kernel: create_mad_qp+0x8e/0xd6 [ib_core]
kernel: ib_mad_port_open+0x268/0x3f2 [ib_core]
GSI QPs reserve allocator ID IB_QPT_GSI directly, whereas ordinary QPs
encode the allocated ID in the QPID. Calling ionic_put_qpid() for a
GSI QP incorrectly applies the ordinary QPID conversion and releases
an unallocated ID.
Release IB_QPT_GSI directly in both the creation error path and the
destruction path.
Fixes: e8521822c733 ("RDMA/ionic: Register device ops for control path")
Cc: <stable@vger.kernel.org>
Reported-by: Keith Lucas <keith.lucas@oracle.com>
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Tested-by: Keith Lucas <keith.lucas@oracle.com>
---
drivers/infiniband/hw/ionic/ionic_controlpath.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/ionic/ionic_controlpath.c b/drivers/infiniband/hw/ionic/ionic_controlpath.c
index a70ef59a8064e..cd623f1de38a3 100644
--- a/drivers/infiniband/hw/ionic/ionic_controlpath.c
+++ b/drivers/infiniband/hw/ionic/ionic_controlpath.c
@@ -2450,7 +2450,11 @@ int ionic_create_qp(struct ib_qp *ibqp, struct ib_qp_init_attr *attr,
err_ahid:
kfree(qp->hdr);
err_ah_alloc:
- ionic_put_qpid(dev, qp->qpid);
+ if (attr->qp_type == IB_QPT_GSI)
+ ionic_resid_put(&dev->inuse_qpid, IB_QPT_GSI);
+ else
+ ionic_put_qpid(dev, qp->qpid);
+
return rc;
}
@@ -2762,7 +2766,10 @@ int ionic_destroy_qp(struct ib_qp *ibqp, struct ib_udata *udata)
ionic_put_ahid(dev, qp->ahid);
kfree(qp->hdr);
}
- ionic_put_qpid(dev, qp->qpid);
+ if (qp->qpid == IB_QPT_GSI)
+ ionic_resid_put(&dev->inuse_qpid, IB_QPT_GSI);
+ else
+ ionic_put_qpid(dev, qp->qpid);
return 0;
}
--
2.43.5
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH for-next] RDMA/ionic: Fix GSI QP ID release
2026-10-21 16:16 [PATCH for-next] RDMA/ionic: Fix GSI QP ID release Håkon Bugge
@ 2026-10-21 16:29 ` sashiko-bot
0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-10-21 16:29 UTC (permalink / raw)
To: Håkon Bugge; +Cc: linux-rdma
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] RDMA/ionic: QPID 1 collision and wrong IDA free in ionic_destroy_qp()
--
commit edc58ccd1d5e8131fe43b51993df0ab60279d823
Author: Håkon Bugge <haakon.bugge@oracle.com>
RDMA/ionic: Fix GSI QP ID release
This commit changes the error path in ionic_create_qp() and the cleanup path
in ionic_destroy_qp() to release IB_QPT_GSI directly into dev->inuse_qpid
instead of calling ionic_put_qpid() when freeing a GSI QP.
> diff --git a/drivers/infiniband/hw/ionic/ionic_controlpath.c b/drivers/infiniband/hw/ionic/ionic_controlpath.c
> index 18ad967812f50..47904c5b9ce19 100644
> --- a/drivers/infiniband/hw/ionic/ionic_controlpath.c
> +++ b/drivers/infiniband/hw/ionic/ionic_controlpath.c
> @@ -2544,7 +2544,11 @@ int ionic_create_qp(struct ib_qp *ibqp, struct ib_qp_init_attr *attr,
> err_ahid:
> kfree(qp->hdr);
> err_ah_alloc:
> - ionic_put_qpid(dev, qp->qpid);
> + if (attr->qp_type == IB_QPT_GSI)
> + ionic_resid_put(&dev->inuse_qpid, IB_QPT_GSI);
> + else
> + ionic_put_qpid(dev, qp->qpid);
> +
> return rc;
> }
>
> @@ -2858,7 +2862,10 @@ int ionic_destroy_qp(struct ib_qp *ibqp, struct ib_udata *udata)
> ionic_put_ahid(dev, qp->ahid);
> kfree(qp->hdr);
> }
> - ionic_put_qpid(dev, qp->qpid);
> + if (qp->qpid == IB_QPT_GSI)
> + ionic_resid_put(&dev->inuse_qpid, IB_QPT_GSI);
> + else
> + ionic_put_qpid(dev, qp->qpid);
>
> return 0;
> }
[Severity: High]
Does releasing raw IB_QPT_GSI (bitid 1) in dev->inuse_qpid and checking
qp->qpid == IB_QPT_GSI in ionic_destroy_qp() leave the GSI bitid unreserved
and cause ordinary QPs on udma 1 to collide with QPID 1 when
dev->lif_cfg.udma_qgrp_shift == 0?
The IDA allocator dev->inuse_qpid tracks bit indices (bitid), which
ionic_get_qpid() and ionic_put_qpid() convert to and from queue IDs (qpid)
using ionic_bitid_to_qid() and ionic_qid_to_bitid().
In the configuration from the commit message where ionic_put_qpid(dev, 1)
passes id=32 to ida_free() (dev->lif_cfg.udma_qgrp_shift == 0 and
dev->half_qpid_udma_shift == 5), ionic_qid_to_bitid(IB_QPT_GSI, 0, 5) is 32,
and its inverse ionic_bitid_to_qid(32, 0, 5) is 1 (IB_QPT_GSI). Meanwhile,
bitid 1 maps to qpid 2 on udma 0.
In drivers/infiniband/hw/ionic/ionic_controlpath.c, ionic_get_gsi_qpid()
reserves raw bitid 1 instead of the bitid corresponding to IB_QPT_GSI:
rc = ionic_resid_get_shared(&dev->inuse_qpid, IB_QPT_GSI, IB_QPT_GSI + 1);
if (rc < 0)
return rc;
*qpid = IB_QPT_GSI;
And in ionic_get_qpid(), the reserved QPID check only skips bitids 0 and 1
when base == 0 (udma_ix == 0):
size = dev->lif_cfg.qp_count / dev->lif_cfg.udma_count;
base = size * udma_ix;
bound = base + size;
/* skip reserved SMI and GSI qpids in group zero */
if (!base)
base = 2;
rc = ionic_resid_get_shared(&dev->inuse_qpid, base, bound);
if (rc >= 0) {
*qpid = ionic_bitid_to_qid(rc,
dev->lif_cfg.udma_qgrp_shift,
dev->half_qpid_udma_shift);
When dev->lif_cfg.udma_qgrp_shift == 0 and an ordinary QP is allocated on
udma_ix == 1 (base == 32), bitid 32 is not reserved in dev->inuse_qpid, so
ionic_get_qpid() allocates bitid 32 and sets *qpid = 1 (IB_QPT_GSI).
If GSI QP creation failed earlier so no GSI QP exists, that ordinary QP is
created with qp->qpid == 1 backed by bitid 32. When that ordinary QP is later
destroyed, wouldn't ionic_destroy_qp() see qp->qpid == IB_QPT_GSI and call
ionic_resid_put(&dev->inuse_qpid, IB_QPT_GSI), freeing unallocated bitid 1
(triggering the ida_free() warning for id=1) and leaking bitid 32?
Also, if the GSI QP is active at QPID 1 when an ordinary QP on udma_ix == 1
is assigned qp->qpid == 1 in ionic_create_qp():
entry = xa_store_irq(&dev->qp_tbl, qp->qpid, qp, GFP_KERNEL);
if (entry) {
if (!xa_is_err(entry))
rc = -EINVAL;
else
rc = xa_err(entry);
goto err_qp_cmd;
}
can xa_store_irq() overwrite the active GSI QP in dev->qp_tbl[1] with the new
qp and jump to err_qp_cmd, destroying QPID 1 in firmware via
ionic_destroy_qp_cmd(dev, 1) and leaving a dangling pointer to the freed
ordinary qp in dev->qp_tbl[1]?
Would it make more sense for ionic_get_gsi_qpid() to reserve
ionic_qid_to_bitid(IB_QPT_GSI, dev->lif_cfg.udma_qgrp_shift,
dev->half_qpid_udma_shift) in dev->inuse_qpid (and for ionic_get_qpid() to
only skip bitid 0 on udma 0 when udma_qgrp_shift == 0), so that
ionic_put_qpid(dev, qp->qpid) works uniformly for both GSI and ordinary QPs?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261021161651.4020222-1-haakon.bugge@oracle.com?part=1
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-10-21 16:29 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-21 16:16 [PATCH for-next] RDMA/ionic: Fix GSI QP ID release Håkon Bugge
2026-10-21 16:29 ` sashiko-bot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox