<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/next/linux-next.git/drivers/infiniband, branch fs-current</title>
<subtitle>The linux-next integration testing tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/atom?h=fs-current</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/atom?h=fs-current'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/'/>
<updated>2026-07-05T11:02:35+00:00</updated>
<entry>
<title>RDMA/irdma: Prevent overflows in memory contiguity checks</title>
<updated>2026-07-05T11:02:35+00:00</updated>
<author>
<name>Aleksandrova Alyona</name>
<email>aga@itb.spb.ru</email>
</author>
<published>2026-06-24T14:48:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=3cda0dfe8c651dcbb9e38977905d3d3b1750c4ab'/>
<id>urn:sha1:3cda0dfe8c651dcbb9e38977905d3d3b1750c4ab</id>
<content type='text'>
irdma_check_mem_contiguous() and irdma_check_mr_contiguous() verify that
PBL entries describe physically contiguous memory ranges.

Both functions calculate byte offsets using 32-bit operands. For example,
with 4 KiB pages, pg_size * pg_idx overflows 32-bit arithmetic when
pg_idx reaches 1048576. In the level-2 check, PBLE_PER_PAGE is 512, so
i * pg_size * PBLE_PER_PAGE overflows when i reaches 2048.

These values are reachable in the driver. For MRs, palloc-&gt;total_cnt
comes from iwmr-&gt;page_cnt, which is calculated by
ib_umem_num_dma_blocks(). The MR size is limited by IRDMA_MAX_MR_SIZE,
so a 4 GiB MR with 4 KiB pages can reach page_cnt of 1048576. PBLE
resources do not exclude this value either: for gen3, the limit is based
on avail_sds * MAX_PBLE_PER_SD, and MAX_PBLE_PER_SD is 0x40000, so 4 SDs
are enough for 1048576 PBLEs.

Cast one operand to u64 before the multiplications so that the offset
calculations are performed in 64-bit arithmetic.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
Signed-off-by: Aleksandrova Alyona &lt;aga@itb.spb.ru&gt;
Link: https://patch.msgid.link/20260624144846.61242-1-aga@itb.spb.ru
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
</content>
</entry>
<entry>
<title>RDMA/siw: publish QP after initialization</title>
<updated>2026-07-02T17:37:03+00:00</updated>
<author>
<name>Ruoyu Wang</name>
<email>ruoyuw560@gmail.com</email>
</author>
<published>2026-06-30T06:00:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=bb27fcc67c429d97f785c92c35a6c5adebb05d7f'/>
<id>urn:sha1:bb27fcc67c429d97f785c92c35a6c5adebb05d7f</id>
<content type='text'>
siw_create_qp() currently calls siw_qp_add() before the queues, CQ
pointers, state, completion, and device list entry are ready. A QPN
lookup can therefore reach a QP that is still being constructed.

Move siw_qp_add() to the end of siw_create_qp(), after QP
initialization and before adding the QP to the siw device list.

Fixes: f29dd55b0236 ("rdma/siw: queue pair methods")
Link: https://patch.msgid.link/r/20260630060040.966461-1-ruoyuw560@gmail.com
Suggested-by: Bernard Metzler &lt;bernard.metzler@linux.dev&gt;
Signed-off-by: Ruoyu Wang &lt;ruoyuw560@gmail.com&gt;
Acked-by: Bernard Metzler &lt;bernard.metzler@linux.dev&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
</content>
</entry>
<entry>
<title>RDMA/hns: Fix potential integer overflow in mhop hem cleanup</title>
<updated>2026-07-02T17:24:15+00:00</updated>
<author>
<name>Danila Chernetsov</name>
<email>listdansp@mail.ru</email>
</author>
<published>2026-06-27T09:59:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=9f0f2d2121f16d420199a82ac5bbc242269133b3'/>
<id>urn:sha1:9f0f2d2121f16d420199a82ac5bbc242269133b3</id>
<content type='text'>
In hns_roce_cleanup_mhop_hem_table(), the expression:

    obj = i * buf_chunk_size / table-&gt;obj_size;

is evaluated using 32-bit unsigned arithmetic because
'buf_chunk_size' is u32 and the usual arithmetic conversions convert
'i' to unsigned int. The result is assigned to a u64 variable, but the
multiplication may overflow before the assignment.

For sufficiently large HEM tables, this produces an incorrect object
index passed to hns_roce_table_mhop_put().

Cast 'i' to u64 before the multiplication so that the intermediate
calculation is performed with 64-bit arithmetic.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: a25d13cbe816 ("RDMA/hns: Add the interfaces to support multi hop addressing for the contexts in hip08")
Link: https://patch.msgid.link/r/20260627095951.51378-1-listdansp@mail.ru
Signed-off-by: Danila Chernetsov &lt;listdansp@mail.ru&gt;
Reviewed-by: Junxian Huang &lt;huangjunxian6@hisilicon.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
</content>
</entry>
<entry>
<title>RDMA/core: Fix memory leak in __ib_create_cq() on invalid cqe</title>
<updated>2026-07-02T17:19:33+00:00</updated>
<author>
<name>Chenguang Zhao</name>
<email>zhaochenguang@kylinos.cn</email>
</author>
<published>2026-06-25T02:01:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=e939334ea7dd219f100f963dbb1cb43df520c20a'/>
<id>urn:sha1:e939334ea7dd219f100f963dbb1cb43df520c20a</id>
<content type='text'>
Move the zero CQE validation before rdma_zalloc_drv_obj() to avoid
leaking the CQ object when returning -EINVAL.

Fixes: a2917582887a ("RDMA/core: Reject zero CQE count")
Link: https://patch.msgid.link/r/20260625020148.224537-1-zhaochenguang@kylinos.cn
Signed-off-by: Chenguang Zhao &lt;zhaochenguang@kylinos.cn&gt;
Reviewed-by: Kalesh AP &lt;kalesh-anakkur.purayil@broadcom.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
</content>
</entry>
<entry>
<title>RDMA/mana_ib: initialize err for empty send WR lists</title>
<updated>2026-07-02T17:16:44+00:00</updated>
<author>
<name>Ruoyu Wang</name>
<email>ruoyuw560@gmail.com</email>
</author>
<published>2026-06-18T04:17:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=155fd5ce2382b0ffbec0d7ee7b3a6818a27a5aed'/>
<id>urn:sha1:155fd5ce2382b0ffbec0d7ee7b3a6818a27a5aed</id>
<content type='text'>
mana_ib_post_send() returns err after walking the send work request list.
If the caller passes an empty list, the loop is skipped and err is not
assigned.

Initialize err to 0 so an empty send work request list returns success
instead of stack data.

Fixes: c8017f5b4856 ("RDMA/mana_ib: UD/GSI work requests")
Link: https://patch.msgid.link/r/20260618041752.481193-2-ruoyuw560@gmail.com
Signed-off-by: Ruoyu Wang &lt;ruoyuw560@gmail.com&gt;
Reviewed-by: Long Li &lt;longli@microsoft.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
</content>
</entry>
<entry>
<title>RDMA/erdma: initialize ret for empty receive WR lists</title>
<updated>2026-07-02T17:16:44+00:00</updated>
<author>
<name>Ruoyu Wang</name>
<email>ruoyuw560@gmail.com</email>
</author>
<published>2026-06-18T04:17:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=2815a277c53e9a84784d6410cd55a9da5b33068d'/>
<id>urn:sha1:2815a277c53e9a84784d6410cd55a9da5b33068d</id>
<content type='text'>
erdma_post_recv() returns ret after walking the receive work request list.
If the caller passes an empty list, the loop is skipped and ret is not
assigned.

Initialize ret to 0 so an empty receive work request list returns success
instead of stack data.

Fixes: 155055771704 ("RDMA/erdma: Add verbs implementation")
Link: https://patch.msgid.link/r/20260618041752.481193-1-ruoyuw560@gmail.com
Signed-off-by: Ruoyu Wang &lt;ruoyuw560@gmail.com&gt;
Reviewed-by: Cheng Xu &lt;chengyou@linux.alibaba.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
</content>
</entry>
<entry>
<title>RDMA/irdma: Prevent user-triggered null deref on QP create</title>
<updated>2026-07-02T17:02:48+00:00</updated>
<author>
<name>Jacob Moroni</name>
<email>jmoroni@google.com</email>
</author>
<published>2026-06-17T16:40:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=b9b0889071569d43623c260074e159cd8f26adb1'/>
<id>urn:sha1:b9b0889071569d43623c260074e159cd8f26adb1</id>
<content type='text'>
Previously, the user QP creation path would only attempt to
populate iwqp-&gt;iwpbl if the user-provided req.user_wqe_bufs
field was non-zero. The problem is that iwqp-&gt;iwpbl is
unconditionally dereferenced later on in irdma_setup_virt_qp.

While there was a check for iwqp-&gt;iwpbl != NULL, this check
would only occur if req.user_wqe_bufs was non-zero. The end
result is that a user could send a zero user_wqe_bufs value
and trigger a null ptr deref.

Fix this by unconditionally calling irdma_get_pbl and bailing
if it fails, similar to the CQ and SRQ paths.

Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
Link: https://patch.msgid.link/r/20260617164013.280790-1-jmoroni@google.com
Signed-off-by: Jacob Moroni &lt;jmoroni@google.com&gt;
Reviewed-by: David Hu &lt;xuehaohu@google.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
</content>
</entry>
<entry>
<title>RDMA/irdma: Prevent rereg_mr for non-mem regions</title>
<updated>2026-07-02T12:03:38+00:00</updated>
<author>
<name>Jacob Moroni</name>
<email>jmoroni@google.com</email>
</author>
<published>2026-06-17T14:19:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a846aecb931b4d65d5eafa92a0623545af46d4f2'/>
<id>urn:sha1:a846aecb931b4d65d5eafa92a0623545af46d4f2</id>
<content type='text'>
When a QP/CQ/SRQ is created, a two step process is used
where the buffer is allocated in userspace and explicitly
registered with the normal reg_mr mechanism prior to creating
the actual QP/CQ/SRQ object.

These special registrations are indicated via an ABI field
so the driver knows that they do not have a valid mkey and
to skip the actual CQP command submission.

Since these are real MR objects from the core's perspective,
it is possible for a user application to invoke rereg_mr on them
and cause a real CQP op to be emitted with the zero-initialized
mkey value of 0.

Fix this by preventing rereg_mr on these special regions.

Fixes: 5ac388db27c4 ("RDMA/irdma: Add support to re-register a memory region")
Signed-off-by: Jacob Moroni &lt;jmoroni@google.com&gt;
Reviewed-by: David Hu &lt;xuehaohu@google.com&gt;
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
</content>
</entry>
<entry>
<title>RDMA/cma: Fix hardware address comparison length in netevent callback</title>
<updated>2026-07-02T11:03:46+00:00</updated>
<author>
<name>Or Gerlitz</name>
<email>ogerlitz@ddn.com</email>
</author>
<published>2026-06-17T11:21:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=18313833e2c6de222a4f6c072da759d0d5888528'/>
<id>urn:sha1:18313833e2c6de222a4f6c072da759d0d5888528</id>
<content type='text'>
The cited commit hardcoded the hardware address comparison len to ETH_ALEN.

This breaks IPoIB, which uses 20-byte addresses. By truncating the
memcmp, the CMA may incorrectly assume the target address is
unchanged and fails to abort the stalled connection.

Fix this by replacing ETH_ALEN with the dynamic neigh-&gt;dev-&gt;addr_len
to correctly evaluate the full address regardless of the link layer.

Fixes: 925d046e7e52 ("RDMA/core: Add a netevent notifier to cma")
Signed-off-by: Or Gerlitz &lt;ogerlitz@ddn.com&gt;
Link: https://patch.msgid.link/20260617-fix-cma-ipoib-v1-1-03f869344304@ddn.com
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
</content>
</entry>
<entry>
<title>RDMa/mlx5: Avoid frame overflow warning</title>
<updated>2026-07-01T12:33:13+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2026-06-12T20:15:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=f5ad2ead846e3a00d040d64c7eaf67b65629f51d'/>
<id>urn:sha1:f5ad2ead846e3a00d040d64c7eaf67b65629f51d</id>
<content type='text'>
Building mlx5 on s390 shows a rather high stack usage that can exceed
the warning limit when that is set to a lower but still reasonable value:

drivers/infiniband/hw/mlx5/wr.c:1051:5: error: stack frame size (1328) exceeds limit (1280) in 'mlx5_ib_post_send' [-Werror,-Wframe-larger-than]

The problem here is 'struct ib_reg_wr' on the stack of
handle_reg_mr_integrity(), which gets inlined into mlx5_ib_post_send()
along with a number of smaller functions.

Keeping the inner function out of line like gcc does avoids the
warning and reduces the total stack usage in other functions called
from mlx5_ib_post_send(), though handle_reg_mr_integrity() itself
still has the same problem as before.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Link: https://patch.msgid.link/20260612201611.4127750-1-arnd@kernel.org
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
</content>
</entry>
</feed>
