All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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.