From: Serhat Kumral <serhatkumral1@gmail.com>
To: Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>
Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
Serhat Kumral <serhatkumral1@gmail.com>
Subject: [PATCH] RDMA/core: Reject CQE counts above max_cqe in ib_cq_pool_get()
Date: Mon, 31 Aug 2026 20:13:54 +0300 [thread overview]
Message-ID: <20260831171354.72140-1-serhatkumral1@gmail.com> (raw)
ib_cq_pool_get() does not validate nr_cqe against the device limit,
while ib_alloc_cqs() caps the size passed to ib_alloc_cq() at
dev->attrs.max_cqe:
nr_cqes = min(dev->attrs.max_cqe, max(nr_cqes, IB_MAX_SHARED_CQ_SZ));
If nr_cqe is larger than max_cqe, ib_alloc_cqs() cannot ask the device
for that many entries. A device that reports the size it was asked for
therefore returns a CQ smaller than nr_cqe, and the fit test skips
every CQ in the pool:
if (cq->cqe_used + nr_cqe > cq->cqe)
continue;
'found' remains NULL and each iteration calls ib_alloc_cqs() again,
adding another batch of CQs to dev->cq_pools[]. The CQs stay in the
pool, so each walk under cq_pools_lock gets longer. The loop ends only
when an allocation fails, i.e. once the device or the system has run
out of resources.
ib_srpt can reach this path when a privileged user configures
srp_sq_size through configfs. ib_srpt accepts values up to 65535 and
requests ch->rq_size + sq_size CQEs while establishing a connection. If
that sum exceeds max_cqe, a valid connection request from a remote
initiator can trigger the allocation loop.
Reproduced with ib_srpt over rxe, which reports max_cqe = 32767, after
setting srp_sq_size to 65535. In a 1 GB guest, a login attempt
requesting 65663 CQEs caused 115 allocation rounds in 185 ms, followed
by:
Out of memory and no killable processes...
Kernel panic - not syncing: System is deadlocked on memory
Workqueue: ib_cm cm_work_handler
Call Trace:
__vmalloc_node_range_noprof
vmalloc_user_noprof
rxe_queue_init
rxe_cq_from_init
rxe_create_cq
__ib_alloc_cq
ib_cq_pool_get
srpt_cm_req_recv.cold
srpt_rdma_cm_req_recv
cma_cm_event_handler
cma_ib_req_handler
cm_process_work
cm_work_handler
Reject oversized requests before entering the allocation loop. With the
check in place, the same test allocates no CQs and ib_srpt rejects the
login:
ib_srpt failed to create CQ cqe= 65663 ret= -EINVAL
Requests for max_cqe entries or fewer behave as before.
Fixes: c7ff819aefea ("RDMA/core: Introduce shared CQ pool API")
Signed-off-by: Serhat Kumral <serhatkumral1@gmail.com>
---
drivers/infiniband/core/cq.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/infiniband/core/cq.c b/drivers/infiniband/core/cq.c
index 12304c9a9403..1205e9b28897 100644
--- a/drivers/infiniband/core/cq.c
+++ b/drivers/infiniband/core/cq.c
@@ -449,6 +449,13 @@ struct ib_cq *ib_cq_pool_get(struct ib_device *dev, unsigned int nr_cqe,
return ERR_PTR(-EINVAL);
}
+ /*
+ * ib_alloc_cqs() caps CQ size at max_cqe, so a larger request would
+ * keep allocating CQs that never fit until allocation fails.
+ */
+ if (nr_cqe > dev->attrs.max_cqe)
+ return ERR_PTR(-EINVAL);
+
num_comp_vectors =
min_t(unsigned int, dev->num_comp_vectors, num_online_cpus());
/* Project the affinty to the device completion vector range */
base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
--
2.53.0
next reply other threads:[~2026-08-31 17:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 17:13 Serhat Kumral [this message]
2026-09-03 9:49 ` [PATCH] RDMA/core: Reject CQE counts above max_cqe in ib_cq_pool_get() 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=20260831171354.72140-1-serhatkumral1@gmail.com \
--to=serhatkumral1@gmail.com \
--cc=jgg@ziepe.ca \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.