From nobody Tue Sep 29 14:06:01 2026 Received: from mail-wm2-f10.google.com (mail-wm2-f10.google.com [74.125.225.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BF1A92DECBF for ; Thu, 6 Aug 2026 20:14:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.138 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786047282; cv=none; b=sNVrfTQqTwG+NT61x+LH0t4HxDHI4/H5n1zoGE1ms7q7WSe3KDnV2IJol/G5cj2n7AgAmqTq5ExKkFGzLpzgutBMMt4LFay4KWb/9FCIBZCcThQ+IKAbxG4of1S0jnbIXPIE9JIqgn95NaiaS+CPfAN0lVUDCJ2JwGd/y4AwfBs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786047282; c=relaxed/simple; bh=o2btizAO+Ks/0UvqaH7GZKydxvAy1OgOWVYRpiO6bo0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=kVuJBPTY5FpwqcA2vOlj8aND8rNuGTOoc+SAmLs7NU6paQ0DlAQWN+CgvV4VEI5Gx6DhKSPH5y+ImYwf7xDdPIqAMUQMgUKakWBw26gWIeMmvdeZpQKLxTcZwqAZR28qUwlXMCtxwLzu0SbflL9eR2pdgJxVTMQ9Kq0Fcm6wDSQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=i7UQ7gm1; arc=none smtp.client-ip=74.125.225.138 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="i7UQ7gm1" Received: by mail-wm2-f10.google.com with SMTP id 5b1f17b1804b1-495459712d2so5554045e9.1 for ; Thu, 06 Aug 2026 13:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786047269; x=1786652069; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=KptR6YR3bhzGgXjfr9mIisFou0Y2tXrBhy7YKqZAMeo=; b=i7UQ7gm1y43GxtfulJeQUPvx85Q+lFILxtnFI6x0DuMPKcB54Lasc3CcfX9Jyd97ps FyjOxHPgwLQhhuwpu10/9qHGmae6xH3T/2I6N8MCKXFqUvfrrOgMK+y291db/dWGonCB qo9cBU13FQHBi9PmEfA2dfhfZi7gudOtQ62wWESj1K1rcin0SERmdL8I+lkmQ+EgGvjU mH3H2yJDzMPXYbvrHJNcRq0ssqaQpA+fI5Lp0Zf6ZRldoG/O9xp/EEvMNMJADtqVVDOo daVAf6BZLreQ2+cz/eymLvnSi20pNoNNx6ICe3I/J2ZDGF80DwB22LW+sLAcdyKWB0+h xzmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786047269; x=1786652069; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=KptR6YR3bhzGgXjfr9mIisFou0Y2tXrBhy7YKqZAMeo=; b=N3Rn5ZMtmRN74QKQHQdhWivAsUUL4fTWAbYGxxXzssAAdhOm6F+UBiYJIPK0dNOVOj g2KJmpu6zdw2Rd5aE7gYfeh6Hb0x2YeL8kZNdd4Vh5eH6sxNeNYE7q8zf/gIWmNBEETk wAQ+01+0Vgc/X7RgMPs41IPG+9IgLRgm33iHtd2zJGKRphOKJAEH9CoZNWp7otFWTmG6 ac9qkO3LFDgHOodSLv00LekU6wz23ygPSsNJfv/W4OEU3HEBiIDsx7nBLhXQpotYgaMr UaExEm5oF5G3/FCY2gM8ZyxaYJQO1DJdJbvGBHQXgYzGRLm6xJJ+mNLZbQt0xkh+008P SQ8g== X-Forwarded-Encrypted: i=1; AHgh+Rosl2MS2zw+TVCzbDzbNP11uQ/RiEF00QI7Pm1f8NP6Q9X/JGemYl2tX/fw5qUjXHaxBKmwkBv+EVZ/tzk=@vger.kernel.org X-Gm-Message-State: AOJu0YxIVrzJDL9ihIPaa8K4cYFbbZfzpPjlUOWZXNw05lO8SuCjfC7l 7GYw6/UbMe/FDGqK+2vEugBfhhjdI3uZYfFqdOo3k1rSubPIYVfEl1r4 X-Gm-Gg: AR+sD11BBih4IDb+GivGWSV0mAB0nPtG/1AYpbdtF2TSc8gff6XJrtq7leUZ7FouA9x i3VdaRQCJcWwaZU7NOm26nkAXCQezbTcgEwQzguQWQUkdhZaisibF4pYwaiweF/m6WuTRPyVLwm DaM5ALLf1VAc9ugZmKqEUIbD2Q/wUniwmIdru+DI0x/pEqsWAcLaIWfwPVWyI/WbpOuAXCzPf/n S0TkPCeq9uPMhOduGhha5znOWK0IbHYv8zSGOjQ4SIPWPKuulBfGvo6OH6TvfZ2gWsExEWvrniL 6uCDuUOqOsMfUbogapjyhoruhiUejSkBZaXijjudEDzKO40G2y+DvdImYb2y/wv4+nU2/IvXoV7 bQcA7AuY159Vo8FtKCMweN9JaGzWq7O02z5FoHxLcMPSra6NuPS4e0H+tDHCAMsuQJA69KigE/t lHAJObxPdakPbn1QGs/ueyrOgWMxL7zBdi463UW9WoCadYIOnJufTx1bU+Lxka X-Received: by 2002:a05:600c:8b55:b0:495:3de8:33a6 with SMTP id 5b1f17b1804b1-4994e7cdd39mr266039855e9.16.1786047268974; Thu, 06 Aug 2026 13:14:28 -0700 (PDT) Received: from fedora ([212.253.220.176]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4995422016fsm70069855e9.8.2026.08.06.13.14.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 13:14:28 -0700 (PDT) From: Serhat Kumral To: Jason Gunthorpe , Leon Romanovsky Cc: Sean Hefty , linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, Serhat Kumral Subject: [PATCH] RDMA/ucma: Allow path records to exactly fit the output buffer Date: Thu, 6 Aug 2026 23:13:58 +0300 Message-ID: <20260806201358.147478-1-serhatkumral1@gmail.com> X-Mailer: git-send-email 2.55.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" ucma_query_path() emits a path record only when the remaining output buffer is strictly larger than struct ib_path_rec_data. A buffer sized exactly for the response header and N complete records therefore gets only N - 1 records, while resp->num_paths still advertises N. A caller sizing its buffer for a single record gets a header claiming one path and no path data at all. ucma_query_ib_service() in the same file computes the record count with a plain division and so accepts an exact fit; make ucma_query_path() behave the same way. Current librdmacm is unaffected because it always sizes the response for six records while the kernel currently reports at most two paths. Other users of the UAPI that provide an exactly sized buffer can observe the truncated response. Fixes: ac53b264b2f3 ("RDMA/ucma: Support querying when IB paths are not rev= ersible") Signed-off-by: Serhat Kumral --- Reproduced with soft-RoCE (rxe) under qemu, on two 7.2.0-rc3 kernels that differ only in this patch; the kernel config, the test program and the VM were identical across both runs. The test program drives /dev/infiniband/rdma_cm directly so that hdr.out can be set to exactly sizeof(struct rdma_ucm_query_path_resp) + sizeof(struct ib_path_rec_data) =3D 8 + 72 =3D 80 and poisons the response buffer first, so a record slot the kernel never wrote stays recognisable afterwards. Before: requesting room for 1 record(s): hdr.out =3D 80 resp->num_paths (advertised by kernel) =3D 1 record slot 0: UNTOUCHED (still poison) records that fit in the buffer and should have been copied: 1 records actually copied: 0 After: requesting room for 1 record(s): hdr.out =3D 80 resp->num_paths (advertised by kernel) =3D 1 record slot 0: written by kernel flags=3D0x0000002b records that fit in the buffer and should have been copied: 1 records actually copied: 1 flags 0x2b is IB_PATH_GMP | IB_PATH_PRIMARY | IB_PATH_BIDIRECTIONAL, i.e. exactly what ucma_query_path() writes into the record. drivers/infiniband/core/ucma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c index 878561fa1cb5..cfd202325458 100644 --- a/drivers/infiniband/core/ucma.c +++ b/drivers/infiniband/core/ucma.c @@ -951,7 +951,7 @@ static ssize_t ucma_query_path(struct ucma_context *ctx, =20 resp->num_paths =3D ctx->cm_id->route.num_pri_alt_paths; for (i =3D 0, out_len -=3D sizeof(*resp); - i < resp->num_paths && out_len > sizeof(struct ib_path_rec_data); + i < resp->num_paths && out_len >=3D sizeof(struct ib_path_rec_data); i++, out_len -=3D sizeof(struct ib_path_rec_data)) { struct sa_path_rec *rec =3D &ctx->cm_id->route.path_rec[i]; =20 --=20 2.55.0