<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include/rdma/ib_verbs.h, branch v6.18.22</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.22</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.22'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2025-07-23T05:42:11+00:00</updated>
<entry>
<title>IB: Extend UVERBS_METHOD_REG_MR to get DMAH</title>
<updated>2025-07-23T05:42:11+00:00</updated>
<author>
<name>Yishai Hadas</name>
<email>yishaih@nvidia.com</email>
</author>
<published>2025-07-17T12:17:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a272019a46c918575f10cc529c893585d46b3b55'/>
<id>urn:sha1:a272019a46c918575f10cc529c893585d46b3b55</id>
<content type='text'>
Extend UVERBS_METHOD_REG_MR to get DMAH and pass it to all drivers.

It will be used in mlx5 driver as part of the next patch from the
series.

Signed-off-by: Yishai Hadas &lt;yishaih@nvidia.com&gt;
Reviewed-by: Edward Srouji &lt;edwards@nvidia.com&gt;
Link: https://patch.msgid.link/2ae1e628c0675db81f092cc00d3ad6fbf6139405.1752752567.git.leon@kernel.org
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
</content>
</entry>
<entry>
<title>RDMA/core: Introduce a DMAH object and its alloc/free APIs</title>
<updated>2025-07-23T05:42:10+00:00</updated>
<author>
<name>Yishai Hadas</name>
<email>yishaih@nvidia.com</email>
</author>
<published>2025-07-17T12:17:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d83edab562a496a42720902a1d2effccd05c37c5'/>
<id>urn:sha1:d83edab562a496a42720902a1d2effccd05c37c5</id>
<content type='text'>
Introduce a new DMA handle (DMAH) object along with its corresponding
allocation and deallocation APIs.

This DMAH object encapsulates attributes intended for use in DMA
transactions.

While its initial purpose is to support TPH functionality, it is
designed to be extensible for future features such as DMA PCI multipath,
PCI UIO configurations, PCI traffic class selection, and more.

Further details:
----------------
We ensure that a caller requesting a DMA handle for a specific CPU ID is
permitted to be scheduled on it. This prevent a potential security issue
where a non privilege user may trigger DMA operations toward a CPU that
it's not allowed to run on.

We manage reference counting for the DMAH object and its consumers
(e.g., memory regions) as will be detailed in subsequent patches in the
series.

Signed-off-by: Yishai Hadas &lt;yishaih@nvidia.com&gt;
Reviewed-by: Edward Srouji &lt;edwards@nvidia.com&gt;
Link: https://patch.msgid.link/2cad097e849597e49d6b61e6865dba878257f371.1752752567.git.leon@kernel.org
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
</content>
</entry>
<entry>
<title>RDMA/uverbs: Add a common way to create CQ with umem</title>
<updated>2025-07-13T08:00:34+00:00</updated>
<author>
<name>Michael Margolin</name>
<email>mrgolin@amazon.com</email>
</author>
<published>2025-07-08T20:23:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1a40c362ae265ca4004f7373b34c22af6810f6cb'/>
<id>urn:sha1:1a40c362ae265ca4004f7373b34c22af6810f6cb</id>
<content type='text'>
Add ioctl command attributes and a common handling for the option to
create CQs with memory buffers passed from userspace. When required
attributes are supplied, create umem and provide it for driver's use.
The extension enables creation of CQs on top of preallocated CPU
virtual or device memory buffers, by supplying VA or dmabuf fd, in a
common way.
Drivers can support this flow by initializing a new create_cq_umem fp
field in their ops struct, with a function that can handle the new
parameter.

Signed-off-by: Michael Margolin &lt;mrgolin@amazon.com&gt;
Link: https://patch.msgid.link/20250708202308.24783-2-mrgolin@amazon.com
Reviewed-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
</content>
</entry>
<entry>
<title>RDMA/uverbs: Add empty rdma_uattrs_has_raw_cap() declaration</title>
<updated>2025-07-09T07:41:21+00:00</updated>
<author>
<name>Leon Romanovsky</name>
<email>leonro@nvidia.com</email>
</author>
<published>2025-07-08T09:31:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=98269398c02ab20eb9ed6d77416023a2627049d8'/>
<id>urn:sha1:98269398c02ab20eb9ed6d77416023a2627049d8</id>
<content type='text'>
The call to rdma_uattrs_has_raw_cap() is placed in mlx5 fs.c file,
which is compiled without relation to CONFIG_INFINIBAND_USER_ACCESS.

Despite the check is used only in flows with CONFIG_INFINIBAND_USER_ACCESS=y|m,
the compilers generate the following error for CONFIG_INFINIBAND_USER_ACCESS=n
builds.

&gt;&gt; ERROR: modpost: "rdma_uattrs_has_raw_cap" [drivers/infiniband/hw/mlx5/mlx5_ib.ko] undefined!

Fixes: f458ccd2aa2c ("RDMA/uverbs: Check CAP_NET_RAW in user namespace for flow create")
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Closes: https://lore.kernel.org/oe-kbuild-all/202507080725.bh7xrhpg-lkp@intel.com/
Link: https://patch.msgid.link/72dee6b379bd709255a5d8e8010b576d50e47170.1751967071.git.leon@kernel.org
Reviewed-by: Zhu Yanjun &lt;yanjun.zhu@linux.dev&gt;
Reviewed-by: Parav Pandit &lt;parav@nvidia.com&gt;
Signed-off-by: Leon Romanovsky &lt;leonro@nvidia.com&gt;
</content>
</entry>
<entry>
<title>RDMA/uverbs: Check CAP_NET_RAW in user namespace for flow create</title>
<updated>2025-07-01T09:21:27+00:00</updated>
<author>
<name>Parav Pandit</name>
<email>parav@nvidia.com</email>
</author>
<published>2025-06-26T18:58:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f458ccd2aa2c5a6f0129a9b1548f2825071fdc6b'/>
<id>urn:sha1:f458ccd2aa2c5a6f0129a9b1548f2825071fdc6b</id>
<content type='text'>
Currently, the capability check is done in the default
init_user_ns user namespace. When a process runs in a
non default user namespace, such check fails. Due to this
when a process is running using Podman, it fails to create
the flow resource.

Since the RDMA device is a resource within a network namespace,
use the network namespace associated with the RDMA device to
determine its owning user namespace.

Fixes: 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow through uverbs")
Signed-off-by: Parav Pandit &lt;parav@nvidia.com&gt;
Suggested-by: Eric W. Biederman &lt;ebiederm@xmission.com&gt;
Link: https://patch.msgid.link/6df6f2f24627874c4f6d041c19dc1f6f29f68f84.1750963874.git.leon@kernel.org
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
</content>
</entry>
<entry>
<title>RDMA/ipoib: Use parent rdma device net namespace</title>
<updated>2025-06-26T12:13:47+00:00</updated>
<author>
<name>Mark Bloch</name>
<email>mbloch@nvidia.com</email>
</author>
<published>2025-06-17T08:44:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f1208b05574f63c52e88109d8c75afdf4fc6bf42'/>
<id>urn:sha1:f1208b05574f63c52e88109d8c75afdf4fc6bf42</id>
<content type='text'>
Use the net namespace of the underlying rdma device.
After honoring the rdma device's namespace, the ipoib
netdev now also runs in the same net namespace of the
rdma device.

Add an API to read the net namespace of the rdma device
so that ULP such as IPoIB can use it to initialize its
netdev.

Signed-off-by: Parav Pandit &lt;parav@nvidia.com&gt;
Signed-off-by: Mark Bloch &lt;mbloch@nvidia.com&gt;
Signed-off-by: Leon Romanovsky &lt;leonro@nvidia.com&gt;
</content>
</entry>
<entry>
<title>RDMA/core: Extend RDMA device registration to be net namespace aware</title>
<updated>2025-06-26T12:10:07+00:00</updated>
<author>
<name>Mark Bloch</name>
<email>mbloch@nvidia.com</email>
</author>
<published>2025-06-17T08:44:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8cffca866ba86cbf0d097e56521b17d830956d4a'/>
<id>urn:sha1:8cffca866ba86cbf0d097e56521b17d830956d4a</id>
<content type='text'>
Presently, RDMA devices are always registered within the init network
namespace, even if the associated devlink device's namespace was
changed via a devlink reload. This mismatch leads to discrepancies
between the network namespace of the devlink device and that of the
RDMA device.

Therefore, extend the RDMA device allocation API to optionally take
the net namespace. This isn't limited to devices that support devlink
but allows all users to provide the network namespace if they need to
do so.

If a network namespace is provided during device allocation, it's up
to the caller to make sure the namespace stays valid until
ib_register_device() is called.

Signed-off-by: Shay Drory &lt;shayd@nvidia.com&gt;
Signed-off-by: Mark Bloch &lt;mbloch@nvidia.com&gt;
Signed-off-by: Leon Romanovsky &lt;leonro@nvidia.com&gt;
</content>
</entry>
<entry>
<title>RDMA/core: Add driver APIs pre_destroy_cq() and post_destroy_cq()</title>
<updated>2025-06-25T07:49:51+00:00</updated>
<author>
<name>Mark Zhang</name>
<email>markzhang@nvidia.com</email>
</author>
<published>2025-06-16T08:26:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5a2a5b65d5d67279be9e1f0e4b9baf39ee594cb1'/>
<id>urn:sha1:5a2a5b65d5d67279be9e1f0e4b9baf39ee594cb1</id>
<content type='text'>
Currently in ib_free_cq, it disables IRQ or cancel the CQ work before
driver destroy_cq. This isn't good as a new IRQ or a CQ work can be
submitted immediately after disabling IRQ or canceling CQ work, which
may run concurrently with destroy_cq and cause crashes.
The right flow should be:
 1. Driver disables CQ to make sure no new CQ event will be submitted;
 2. Disables IRQ or Cancels CQ work in core layer, to make sure no CQ
    polling work is running;
 3. Free all resources to destroy the CQ.

This patch adds 2 driver APIs:
- pre_destroy_cq(): Disable a CQ to prevent it from generating any new
  work completions, but not free any kernel resources;
- post_destroy_cq(): Free all kernel resources.

In ib_free_cq, the IRQ is disabled or CQ work is canceled after
pre_destroy_cq, and before post_destroy_cq.

Fixes: 14d3a3b2498e ("IB: add a proper completion queue abstraction")
Signed-off-by: Mark Zhang &lt;markzhang@nvidia.com&gt;
Link: https://patch.msgid.link/b5f7ae3d75f44a3e15ff3f4eb2bbdea13e06b97f.1750062328.git.leon@kernel.org
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'v6.15' into rdma.git for-next</title>
<updated>2025-05-26T18:33:52+00:00</updated>
<author>
<name>Jason Gunthorpe</name>
<email>jgg@nvidia.com</email>
</author>
<published>2025-05-26T18:32:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ef2233850edc4cc0d5fc6136fcdb004a1ddfa7db'/>
<id>urn:sha1:ef2233850edc4cc0d5fc6136fcdb004a1ddfa7db</id>
<content type='text'>
Following patches need the RDMA rc branch since we are past the RC cycle
now.

Merge conflicts resolved based on Linux-next:

- For RXE odp changes keep for-next version and fixup new places that
  need to call is_odp_mr()
  https://lore.kernel.org/r/20250422143019.500201bd@canb.auug.org.au
  https://lore.kernel.org/r/20250514122455.3593b083@canb.auug.org.au

- irdma is keeping the while/kfree bugfix from -rc and the pf/cdev_info
  change from for-next
  https://lore.kernel.org/r/20250513130630.280ee6c5@canb.auug.org.au

Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
</content>
</entry>
<entry>
<title>RDMA/core: Move ODP capability definitions to uapi</title>
<updated>2025-04-21T11:52:47+00:00</updated>
<author>
<name>Daisuke Matsuda</name>
<email>matsuda-daisuke@fujitsu.com</email>
</author>
<published>2025-04-18T05:13:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=685f9537a72877693a1ab116d155acc89562c29b'/>
<id>urn:sha1:685f9537a72877693a1ab116d155acc89562c29b</id>
<content type='text'>
The bits are used from both kernel space and userland, so they should be
placed in UAPI.

Signed-off-by: Daisuke Matsuda &lt;matsuda-daisuke@fujitsu.com&gt;
Link: https://patch.msgid.link/20250418051345.1022339-2-matsuda-daisuke@fujitsu.com
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
</content>
</entry>
</feed>
