Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

24 participants
3678 discussions

[PATCH 00/61] vfs: change inode->i_ino from unsigned long to u64

by Jeff Layton

Christian said [1] to "just do it" when I proposed this, so here we are! For historical reasons, the inode->i_ino field is an unsigned long, which means that it's 32 bits on 32 bit architectures. This has caused a number of filesystems to implement hacks to hash a 64-bit identifier into a 32-bit field, and deprives us of a universal identifier field for an inode. This patchset changes the inode->i_ino field from an unsigned long to a u64. This shouldn't make any material difference on 64-bit hosts, but 32-bit hosts will see struct inode grow by at least 4 bytes. This could have effects on slabcache sizes and field alignment. The bulk of the changes are to format strings and tracepoints, since the kernel itself doesn't care that much about the i_ino field. The first patch changes some vfs function arguments, so check that one out carefully. With this change, we may be able to shrink some inode structures. For instance, struct nfs_inode has a fileid field that holds the 64-bit inode number. With this set of changes, that field could be eliminated. I'd rather leave that sort of cleanups for later just to keep this simple. Much of this set was generated by LLM, but I attributed it to myself since I consider this to be in the "menial tasks" category of LLM usage. [1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@… Signed-off-by: Jeff Layton <jlayton(a)kernel.org> --- Jeff Layton (61): vfs: widen inode hash/lookup functions to u64 vfs: change i_ino from unsigned long to u64 trace: update VFS-layer trace events for u64 i_ino ext4: update for u64 i_ino jbd2: update format strings for u64 i_ino f2fs: update for u64 i_ino lockd: update format strings for u64 i_ino nfs: update for u64 i_ino nfs: remove nfs_fattr_to_ino_t() and nfs_fileid_to_ino_t() nfs: remove nfs_compat_user_ino64() nfs: remove enable_ino64 module parameter nfsd: update format strings for u64 i_ino smb: store full 64-bit uniqueid in i_ino smb: remove cifs_uniqueid_to_ino_t() locks: update /proc/locks format for u64 i_ino proc: update /proc/PID/maps for u64 i_ino nilfs2: update for u64 i_ino 9p: update format strings for u64 i_ino affs: update format strings for u64 i_ino afs: update format strings for u64 i_ino autofs: update format strings for u64 i_ino befs: update format strings for u64 i_ino bfs: update format strings for u64 i_ino cachefiles: update format strings for u64 i_ino ceph: update format strings for u64 i_ino coda: update format strings for u64 i_ino cramfs: update format strings for u64 i_ino ecryptfs: update format strings for u64 i_ino efs: update format strings for u64 i_ino exportfs: update format strings for u64 i_ino ext2: update format strings for u64 i_ino freevxfs: update format strings for u64 i_ino hfs: update format strings for u64 i_ino hfsplus: update format strings for u64 i_ino hpfs: update format strings for u64 i_ino isofs: update format strings for u64 i_ino jffs2: update format strings for u64 i_ino jfs: update format strings for u64 i_ino minix: update format strings for u64 i_ino nsfs: update format strings for u64 i_ino ntfs3: update format strings for u64 i_ino ocfs2: update format strings for u64 i_ino orangefs: update format strings for u64 i_ino overlayfs: update format strings for u64 i_ino qnx4: update format strings for u64 i_ino qnx6: update format strings for u64 i_ino ubifs: update format strings for u64 i_ino udf: update format strings for u64 i_ino ufs: update format strings for u64 i_ino zonefs: update format strings for u64 i_ino security: update audit format strings for u64 i_ino drm/amdgpu: update for u64 i_ino fsnotify: update fdinfo format strings for u64 i_ino net: update socket dname format for u64 i_ino uprobes: update format strings for u64 i_ino dma-buf: update format string for u64 i_ino fscrypt: update format strings for u64 i_ino fsverity: update format string for u64 i_ino iomap: update format string for u64 i_ino net: update legacy protocol format strings for u64 i_ino vfs: update core format strings for u64 i_ino drivers/dma-buf/dma-buf.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +- fs/9p/vfs_addr.c | 4 +- fs/9p/vfs_inode.c | 6 +- fs/9p/vfs_inode_dotl.c | 6 +- fs/affs/amigaffs.c | 8 +- fs/affs/bitmap.c | 2 +- fs/affs/dir.c | 2 +- fs/affs/file.c | 20 +- fs/affs/inode.c | 12 +- fs/affs/namei.c | 14 +- fs/affs/symlink.c | 2 +- fs/afs/dir.c | 10 +- fs/afs/dir_search.c | 2 +- fs/afs/dynroot.c | 2 +- fs/afs/inode.c | 2 +- fs/autofs/inode.c | 2 +- fs/befs/linuxvfs.c | 28 +- fs/bfs/dir.c | 4 +- fs/cachefiles/io.c | 6 +- fs/cachefiles/namei.c | 12 +- fs/cachefiles/xattr.c | 2 +- fs/ceph/crypto.c | 4 +- fs/coda/dir.c | 2 +- fs/coda/inode.c | 2 +- fs/cramfs/inode.c | 2 +- fs/crypto/crypto.c | 2 +- fs/crypto/hooks.c | 2 +- fs/crypto/keysetup.c | 2 +- fs/dcache.c | 4 +- fs/ecryptfs/crypto.c | 6 +- fs/ecryptfs/file.c | 2 +- fs/efs/inode.c | 6 +- fs/eventpoll.c | 2 +- fs/exportfs/expfs.c | 4 +- fs/ext2/dir.c | 10 +- fs/ext2/ialloc.c | 9 +- fs/ext2/inode.c | 2 +- fs/ext2/xattr.c | 14 +- fs/ext4/dir.c | 2 +- fs/ext4/ext4.h | 4 +- fs/ext4/extents.c | 8 +- fs/ext4/extents_status.c | 28 +- fs/ext4/fast_commit.c | 8 +- fs/ext4/ialloc.c | 10 +- fs/ext4/indirect.c | 2 +- fs/ext4/inline.c | 14 +- fs/ext4/inode.c | 22 +- fs/ext4/ioctl.c | 4 +- fs/ext4/mballoc.c | 6 +- fs/ext4/migrate.c | 2 +- fs/ext4/move_extent.c | 20 +- fs/ext4/namei.c | 10 +- fs/ext4/orphan.c | 16 +- fs/ext4/page-io.c | 10 +- fs/ext4/super.c | 22 +- fs/ext4/xattr.c | 10 +- fs/f2fs/compress.c | 4 +- fs/f2fs/dir.c | 2 +- fs/f2fs/extent_cache.c | 8 +- fs/f2fs/f2fs.h | 6 +- fs/f2fs/file.c | 12 +- fs/f2fs/gc.c | 2 +- fs/f2fs/inline.c | 4 +- fs/f2fs/inode.c | 48 ++-- fs/f2fs/namei.c | 8 +- fs/f2fs/node.c | 12 +- fs/f2fs/recovery.c | 10 +- fs/f2fs/xattr.c | 10 +- fs/freevxfs/vxfs_bmap.c | 4 +- fs/fserror.c | 2 +- fs/hfs/catalog.c | 2 +- fs/hfs/extent.c | 4 +- fs/hfs/inode.c | 4 +- fs/hfsplus/attributes.c | 10 +- fs/hfsplus/catalog.c | 2 +- fs/hfsplus/dir.c | 6 +- fs/hfsplus/extents.c | 6 +- fs/hfsplus/inode.c | 8 +- fs/hfsplus/super.c | 6 +- fs/hfsplus/xattr.c | 10 +- fs/hpfs/dir.c | 4 +- fs/hpfs/dnode.c | 4 +- fs/hpfs/ea.c | 4 +- fs/hpfs/inode.c | 4 +- fs/inode.c | 46 ++-- fs/iomap/ioend.c | 2 +- fs/isofs/compress.c | 2 +- fs/isofs/dir.c | 2 +- fs/isofs/inode.c | 6 +- fs/isofs/namei.c | 2 +- fs/jbd2/journal.c | 4 +- fs/jbd2/transaction.c | 2 +- fs/jffs2/dir.c | 4 +- fs/jffs2/file.c | 4 +- fs/jffs2/fs.c | 18 +- fs/jfs/inode.c | 2 +- fs/jfs/jfs_imap.c | 2 +- fs/jfs/jfs_metapage.c | 2 +- fs/lockd/svclock.c | 8 +- fs/lockd/svcsubs.c | 2 +- fs/locks.c | 6 +- fs/minix/inode.c | 10 +- fs/nfs/dir.c | 22 +- fs/nfs/file.c | 8 +- fs/nfs/filelayout/filelayout.c | 8 +- fs/nfs/flexfilelayout/flexfilelayout.c | 8 +- fs/nfs/inode.c | 54 +--- fs/nfs/nfs4proc.c | 4 +- fs/nfs/pnfs.c | 12 +- fs/nfsd/export.c | 2 +- fs/nfsd/nfs4state.c | 4 +- fs/nfsd/nfsfh.c | 4 +- fs/nfsd/vfs.c | 2 +- fs/nilfs2/alloc.c | 10 +- fs/nilfs2/bmap.c | 2 +- fs/nilfs2/btnode.c | 2 +- fs/nilfs2/btree.c | 12 +- fs/nilfs2/dir.c | 12 +- fs/nilfs2/direct.c | 4 +- fs/nilfs2/gcinode.c | 2 +- fs/nilfs2/inode.c | 8 +- fs/nilfs2/mdt.c | 2 +- fs/nilfs2/namei.c | 2 +- fs/nilfs2/segment.c | 2 +- fs/notify/fdinfo.c | 4 +- fs/nsfs.c | 4 +- fs/ntfs3/super.c | 2 +- fs/ocfs2/alloc.c | 2 +- fs/ocfs2/aops.c | 4 +- fs/ocfs2/dir.c | 8 +- fs/ocfs2/dlmfs/dlmfs.c | 10 +- fs/ocfs2/extent_map.c | 12 +- fs/ocfs2/inode.c | 2 +- fs/ocfs2/quota_local.c | 2 +- fs/ocfs2/refcounttree.c | 10 +- fs/ocfs2/xattr.c | 4 +- fs/orangefs/inode.c | 2 +- fs/overlayfs/export.c | 2 +- fs/overlayfs/namei.c | 4 +- fs/overlayfs/util.c | 2 +- fs/pipe.c | 2 +- fs/proc/fd.c | 2 +- fs/proc/task_mmu.c | 4 +- fs/qnx4/inode.c | 4 +- fs/qnx6/inode.c | 2 +- fs/smb/client/cifsfs.h | 17 -- fs/smb/client/inode.c | 6 +- fs/smb/client/readdir.c | 2 +- fs/ubifs/debug.c | 8 +- fs/ubifs/dir.c | 28 +- fs/ubifs/file.c | 28 +- fs/ubifs/journal.c | 6 +- fs/ubifs/super.c | 16 +- fs/ubifs/tnc.c | 4 +- fs/ubifs/xattr.c | 14 +- fs/udf/directory.c | 18 +- fs/udf/file.c | 2 +- fs/udf/inode.c | 12 +- fs/udf/namei.c | 8 +- fs/udf/super.c | 2 +- fs/ufs/balloc.c | 6 +- fs/ufs/dir.c | 10 +- fs/ufs/ialloc.c | 6 +- fs/ufs/inode.c | 18 +- fs/ufs/ufs_fs.h | 6 +- fs/ufs/util.c | 2 +- fs/verity/init.c | 2 +- fs/zonefs/super.c | 8 +- include/linux/fs.h | 28 +- include/linux/nfs_fs.h | 10 - include/trace/events/cachefiles.h | 18 +- include/trace/events/ext4.h | 427 +++++++++++++++-------------- include/trace/events/f2fs.h | 172 ++++++------ include/trace/events/filelock.h | 16 +- include/trace/events/filemap.h | 20 +- include/trace/events/fs_dax.h | 20 +- include/trace/events/fsverity.h | 30 +- include/trace/events/hugetlbfs.h | 28 +- include/trace/events/netfs.h | 4 +- include/trace/events/nilfs2.h | 12 +- include/trace/events/readahead.h | 12 +- include/trace/events/timestamp.h | 12 +- include/trace/events/writeback.h | 148 +++++----- kernel/events/uprobes.c | 4 +- net/netrom/af_netrom.c | 4 +- net/rose/af_rose.c | 4 +- net/socket.c | 2 +- net/x25/x25_proc.c | 4 +- security/apparmor/apparmorfs.c | 4 +- security/integrity/integrity_audit.c | 2 +- security/ipe/audit.c | 2 +- security/lsm_audit.c | 10 +- security/selinux/hooks.c | 4 +- security/smack/smack_lsm.c | 12 +- 195 files changed, 1101 insertions(+), 1166 deletions(-) --- base-commit: 2bf35e96cf6c6c3a290b69b777d34be15888e364 change-id: 20260224-iino-u64-b44a3a72543c Best regards, -- Jeff Layton <jlayton(a)kernel.org>

8 months

[PATCH] dma-buf: heaps: Add Coherent heap to dmabuf heaps

by Albert Esteve

Add a dma-buf heap for DT coherent reserved-memory (i.e., 'shared-dma-pool' without 'reusable' property), exposing one heap per region for userspace buffers. The heap binds a synthetic platform device to each region so coherent allocations use the correct dev->dma_mem, and it defers registration until late_initcall when normal allocator are available. This patch includes charging of the coherent heap allocator to the dmem cgroup. Signed-off-by: Albert Esteve <aesteve(a)redhat.com> --- This patch introduces a new driver to expose DT coherent reserved-memory regions as dma-buf heaps, allowing userspace buffers to be created. Since these regions are device-dependent, we bind a synthetic platform device to each region so coherent allocations use the correct dev->dma_mem. Following Eric’s [1] and Maxime’s [2] work on charging DMA buffers allocated from userspace to cgroups (dmem), this patch adds the same charging pattern used by CMA heaps patch. Charging is done only through the dma-buf heap interface so it can be attributed to a userspace allocator. This allows each device-specific reserved-memory region to enforce its own limits. [1] https://lore.kernel.org/all/20260218-dmabuf-heap-cma-dmem-v2-0-b249886fb7b2… [2] https://lore.kernel.org/all/20250310-dmem-cgroups-v1-0-2984c1bc9312@kernel.… --- drivers/dma-buf/heaps/Kconfig | 17 ++ drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/coherent_heap.c | 485 ++++++++++++++++++++++++++++++++++ include/linux/dma-heap.h | 11 + kernel/dma/coherent.c | 9 + 5 files changed, 523 insertions(+) diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig index a5eef06c42264..93765dca164e3 100644 --- a/drivers/dma-buf/heaps/Kconfig +++ b/drivers/dma-buf/heaps/Kconfig @@ -12,3 +12,20 @@ config DMABUF_HEAPS_CMA Choose this option to enable dma-buf CMA heap. This heap is backed by the Contiguous Memory Allocator (CMA). If your system has these regions, you should say Y here. + +config DMABUF_HEAPS_COHERENT + bool "DMA-BUF Coherent Reserved-Memory Heap" + depends on DMABUF_HEAPS && OF_RESERVED_MEM && DMA_DECLARE_COHERENT + help + Choose this option to enable coherent reserved-memory dma-buf heaps. + This heap is backed by non-reusable DT "shared-dma-pool" regions. + If your system defines coherent reserved-memory regions, you should + say Y here. + +config COHERENT_AREAS_DEFERRED + int "Max deferred coherent reserved-memory regions" + depends on DMABUF_HEAPS_COHERENT + default 16 + help + Maximum number of coherent reserved-memory regions that can be + deferred for later registration during early boot. diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile index 974467791032f..96bda7a65f041 100644 --- a/drivers/dma-buf/heaps/Makefile +++ b/drivers/dma-buf/heaps/Makefile @@ -1,3 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o +obj-$(CONFIG_DMABUF_HEAPS_COHERENT) += coherent_heap.o diff --git a/drivers/dma-buf/heaps/coherent_heap.c b/drivers/dma-buf/heaps/coherent_heap.c new file mode 100644 index 0000000000000..870b2b89aefcb --- /dev/null +++ b/drivers/dma-buf/heaps/coherent_heap.c @@ -0,0 +1,485 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * DMABUF heap for coherent reserved-memory regions + * + * Copyright (C) 2026 Red Hat, Inc. + * Author: Albert Esteve <aesteve(a)redhat.com> + * + */ + +#include <linux/cgroup_dmem.h> +#include <linux/dma-heap.h> +#include <linux/dma-buf.h> +#include <linux/dma-mapping.h> +#include <linux/err.h> +#include <linux/highmem.h> +#include <linux/iosys-map.h> +#include <linux/of_reserved_mem.h> +#include <linux/platform_device.h> +#include <linux/scatterlist.h> +#include <linux/slab.h> +#include <linux/vmalloc.h> + +#define DEFERRED_AREAS_MAX CONFIG_COHERENT_AREAS_DEFERRED + +/* + * Early init can't use normal memory management yet (memblock is used + * instead), so keep a small deferred list and retry at late_initcall. + */ +static struct reserved_mem *rmem_areas_deferred[DEFERRED_AREAS_MAX]; +static unsigned int rmem_areas_deferred_num; + +static int coherent_heap_add_deferred(struct reserved_mem *rmem) +{ + if (rmem_areas_deferred_num >= DEFERRED_AREAS_MAX) { + pr_warn("Deferred heap areas list full, dropping %s\n", + rmem->name ? rmem->name : "unknown"); + return -EINVAL; + } + rmem_areas_deferred[rmem_areas_deferred_num++] = rmem; + return 0; +} + +struct coherent_heap { + struct dma_heap *heap; + struct reserved_mem *rmem; + char *name; + struct device *dev; + struct platform_device *pdev; +#if IS_ENABLED(CONFIG_CGROUP_DMEM) + struct dmem_cgroup_region *cg; +#endif +}; + +struct coherent_heap_buffer { + struct coherent_heap *heap; + struct list_head attachments; + struct mutex lock; + unsigned long len; + dma_addr_t dma_addr; + void *alloc_vaddr; + struct page **pages; + pgoff_t pagecount; + int vmap_cnt; + void *vaddr; +#if IS_ENABLED(CONFIG_CGROUP_DMEM) + struct dmem_cgroup_pool_state *pool; +#endif +}; + +struct dma_heap_attachment { + struct device *dev; + struct sg_table table; + struct list_head list; + bool mapped; +}; + +static int coherent_heap_attach(struct dma_buf *dmabuf, + struct dma_buf_attachment *attachment) +{ + struct coherent_heap_buffer *buffer = dmabuf->priv; + struct dma_heap_attachment *a; + int ret; + + a = kzalloc_obj(*a); + if (!a) + return -ENOMEM; + + ret = sg_alloc_table_from_pages(&a->table, buffer->pages, + buffer->pagecount, 0, + buffer->pagecount << PAGE_SHIFT, + GFP_KERNEL); + if (ret) { + kfree(a); + return ret; + } + + a->dev = attachment->dev; + INIT_LIST_HEAD(&a->list); + a->mapped = false; + + attachment->priv = a; + + mutex_lock(&buffer->lock); + list_add(&a->list, &buffer->attachments); + mutex_unlock(&buffer->lock); + + return 0; +} + +static void coherent_heap_detach(struct dma_buf *dmabuf, + struct dma_buf_attachment *attachment) +{ + struct coherent_heap_buffer *buffer = dmabuf->priv; + struct dma_heap_attachment *a = attachment->priv; + + mutex_lock(&buffer->lock); + list_del(&a->list); + mutex_unlock(&buffer->lock); + + sg_free_table(&a->table); + kfree(a); +} + +static struct sg_table *coherent_heap_map_dma_buf(struct dma_buf_attachment *attachment, + enum dma_data_direction direction) +{ + struct dma_heap_attachment *a = attachment->priv; + struct sg_table *table = &a->table; + int ret; + + ret = dma_map_sgtable(attachment->dev, table, direction, 0); + if (ret) + return ERR_PTR(-ENOMEM); + a->mapped = true; + + return table; +} + +static void coherent_heap_unmap_dma_buf(struct dma_buf_attachment *attachment, + struct sg_table *table, + enum dma_data_direction direction) +{ + struct dma_heap_attachment *a = attachment->priv; + + a->mapped = false; + dma_unmap_sgtable(attachment->dev, table, direction, 0); +} + +static int coherent_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, + enum dma_data_direction direction) +{ + struct coherent_heap_buffer *buffer = dmabuf->priv; + struct dma_heap_attachment *a; + + mutex_lock(&buffer->lock); + if (buffer->vmap_cnt) + invalidate_kernel_vmap_range(buffer->vaddr, buffer->len); + + list_for_each_entry(a, &buffer->attachments, list) { + if (!a->mapped) + continue; + dma_sync_sgtable_for_cpu(a->dev, &a->table, direction); + } + mutex_unlock(&buffer->lock); + + return 0; +} + +static int coherent_heap_dma_buf_end_cpu_access(struct dma_buf *dmabuf, + enum dma_data_direction direction) +{ + struct coherent_heap_buffer *buffer = dmabuf->priv; + struct dma_heap_attachment *a; + + mutex_lock(&buffer->lock); + if (buffer->vmap_cnt) + flush_kernel_vmap_range(buffer->vaddr, buffer->len); + + list_for_each_entry(a, &buffer->attachments, list) { + if (!a->mapped) + continue; + dma_sync_sgtable_for_device(a->dev, &a->table, direction); + } + mutex_unlock(&buffer->lock); + + return 0; +} + +static int coherent_heap_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma) +{ + struct coherent_heap_buffer *buffer = dmabuf->priv; + struct coherent_heap *coh_heap = buffer->heap; + + return dma_mmap_coherent(coh_heap->dev, vma, buffer->alloc_vaddr, + buffer->dma_addr, buffer->len); +} + +static void *coherent_heap_do_vmap(struct coherent_heap_buffer *buffer) +{ + void *vaddr; + + vaddr = vmap(buffer->pages, buffer->pagecount, VM_MAP, PAGE_KERNEL); + if (!vaddr) + return ERR_PTR(-ENOMEM); + + return vaddr; +} + +static int coherent_heap_vmap(struct dma_buf *dmabuf, struct iosys_map *map) +{ + struct coherent_heap_buffer *buffer = dmabuf->priv; + void *vaddr; + int ret = 0; + + mutex_lock(&buffer->lock); + if (buffer->vmap_cnt) { + buffer->vmap_cnt++; + iosys_map_set_vaddr(map, buffer->vaddr); + goto out; + } + + vaddr = coherent_heap_do_vmap(buffer); + if (IS_ERR(vaddr)) { + ret = PTR_ERR(vaddr); + goto out; + } + + buffer->vaddr = vaddr; + buffer->vmap_cnt++; + iosys_map_set_vaddr(map, buffer->vaddr); +out: + mutex_unlock(&buffer->lock); + + return ret; +} + +static void coherent_heap_vunmap(struct dma_buf *dmabuf, struct iosys_map *map) +{ + struct coherent_heap_buffer *buffer = dmabuf->priv; + + mutex_lock(&buffer->lock); + if (!--buffer->vmap_cnt) { + vunmap(buffer->vaddr); + buffer->vaddr = NULL; + } + mutex_unlock(&buffer->lock); + iosys_map_clear(map); +} + +static void coherent_heap_dma_buf_release(struct dma_buf *dmabuf) +{ + struct coherent_heap_buffer *buffer = dmabuf->priv; + struct coherent_heap *coh_heap = buffer->heap; + + if (buffer->vmap_cnt > 0) { + WARN(1, "%s: buffer still mapped in the kernel\n", __func__); + vunmap(buffer->vaddr); + buffer->vaddr = NULL; + buffer->vmap_cnt = 0; + } + + if (buffer->alloc_vaddr) + dma_free_coherent(coh_heap->dev, buffer->len, buffer->alloc_vaddr, + buffer->dma_addr); + kfree(buffer->pages); +#if IS_ENABLED(CONFIG_CGROUP_DMEM) + dmem_cgroup_uncharge(buffer->pool, buffer->len); +#endif + kfree(buffer); +} + +static const struct dma_buf_ops coherent_heap_buf_ops = { + .attach = coherent_heap_attach, + .detach = coherent_heap_detach, + .map_dma_buf = coherent_heap_map_dma_buf, + .unmap_dma_buf = coherent_heap_unmap_dma_buf, + .begin_cpu_access = coherent_heap_dma_buf_begin_cpu_access, + .end_cpu_access = coherent_heap_dma_buf_end_cpu_access, + .mmap = coherent_heap_mmap, + .vmap = coherent_heap_vmap, + .vunmap = coherent_heap_vunmap, + .release = coherent_heap_dma_buf_release, +}; + +static struct dma_buf *coherent_heap_allocate(struct dma_heap *heap, + unsigned long len, + u32 fd_flags, + u64 heap_flags) +{ + struct coherent_heap *coh_heap; + struct coherent_heap_buffer *buffer; + DEFINE_DMA_BUF_EXPORT_INFO(exp_info); + size_t size = PAGE_ALIGN(len); + pgoff_t pagecount = size >> PAGE_SHIFT; + struct dma_buf *dmabuf; + int ret = -ENOMEM; + pgoff_t pg; + + coh_heap = dma_heap_get_drvdata(heap); + if (!coh_heap) + return ERR_PTR(-EINVAL); + if (!coh_heap->dev) + return ERR_PTR(-ENODEV); + + buffer = kzalloc_obj(*buffer); + if (!buffer) + return ERR_PTR(-ENOMEM); + + INIT_LIST_HEAD(&buffer->attachments); + mutex_init(&buffer->lock); + buffer->len = size; + buffer->heap = coh_heap; + buffer->pagecount = pagecount; + +#if IS_ENABLED(CONFIG_CGROUP_DMEM) + if (mem_accounting) { + ret = dmem_cgroup_try_charge(coh_heap->cg, size, + &buffer->pool, NULL); + if (ret) + goto free_buffer; + } +#endif + + buffer->alloc_vaddr = dma_alloc_coherent(coh_heap->dev, buffer->len, + &buffer->dma_addr, GFP_KERNEL); + if (!buffer->alloc_vaddr) { + ret = -ENOMEM; +#if IS_ENABLED(CONFIG_CGROUP_DMEM) + goto uncharge_cgroup; +#else + goto free_buffer; +#endif + } + + buffer->pages = kmalloc_array(pagecount, sizeof(*buffer->pages), + GFP_KERNEL); + if (!buffer->pages) { + ret = -ENOMEM; + goto free_dma; + } + + for (pg = 0; pg < pagecount; pg++) + buffer->pages[pg] = virt_to_page((char *)buffer->alloc_vaddr + + (pg * PAGE_SIZE)); + + /* create the dmabuf */ + exp_info.exp_name = dma_heap_get_name(heap); + exp_info.ops = &coherent_heap_buf_ops; + exp_info.size = buffer->len; + exp_info.flags = fd_flags; + exp_info.priv = buffer; + dmabuf = dma_buf_export(&exp_info); + if (IS_ERR(dmabuf)) { + ret = PTR_ERR(dmabuf); + goto free_pages; + } + return dmabuf; + +free_pages: + kfree(buffer->pages); +free_dma: + dma_free_coherent(coh_heap->dev, buffer->len, buffer->alloc_vaddr, + buffer->dma_addr); +#if IS_ENABLED(CONFIG_CGROUP_DMEM) +uncharge_cgroup: + dmem_cgroup_uncharge(buffer->pool, size); +#endif +free_buffer: + kfree(buffer); + return ERR_PTR(ret); +} + +static const struct dma_heap_ops coherent_heap_ops = { + .allocate = coherent_heap_allocate, +}; + +static int __coherent_heap_register(struct reserved_mem *rmem) +{ + struct dma_heap_export_info exp_info; + struct coherent_heap *coh_heap; +#if IS_ENABLED(CONFIG_CGROUP_DMEM) + struct dmem_cgroup_region *region; +#endif + const char *rmem_name; + int ret; + + if (!rmem) + return -EINVAL; + + rmem_name = rmem->name ? rmem->name : "unknown"; + + coh_heap = kzalloc_obj(*coh_heap); + if (!coh_heap) + return -ENOMEM; + + coh_heap->name = kasprintf(GFP_KERNEL, "coherent_%s", rmem_name); + if (!coh_heap->name) { + ret = -ENOMEM; + goto free_coherent_heap; + } + + coh_heap->rmem = rmem; + + /* create a platform device per rmem and bind it */ + coh_heap->pdev = platform_device_register_simple("coherent-heap", + PLATFORM_DEVID_AUTO, + NULL, 0); + if (IS_ERR(coh_heap->pdev)) { + ret = PTR_ERR(coh_heap->pdev); + goto free_name; + } + + if (rmem->ops && rmem->ops->device_init) { + ret = rmem->ops->device_init(rmem, &coh_heap->pdev->dev); + if (ret) + goto pdev_unregister; + } + + coh_heap->dev = &coh_heap->pdev->dev; +#if IS_ENABLED(CONFIG_CGROUP_DMEM) + region = dmem_cgroup_register_region(rmem->size, "coh/%s", rmem_name); + if (IS_ERR(region)) { + ret = PTR_ERR(region); + goto pdev_unregister; + } + coh_heap->cg = region; +#endif + + exp_info.name = coh_heap->name; + exp_info.ops = &coherent_heap_ops; + exp_info.priv = coh_heap; + + coh_heap->heap = dma_heap_add(&exp_info); + if (IS_ERR(coh_heap->heap)) { + ret = PTR_ERR(coh_heap->heap); + goto cg_unregister; + } + + return 0; + +cg_unregister: +#if IS_ENABLED(CONFIG_CGROUP_DMEM) + dmem_cgroup_unregister_region(coh_heap->cg); +#endif +pdev_unregister: + platform_device_unregister(coh_heap->pdev); + coh_heap->pdev = NULL; +free_name: + kfree(coh_heap->name); +free_coherent_heap: + kfree(coh_heap); + + return ret; +} + +int dma_heap_coherent_register(struct reserved_mem *rmem) +{ + int ret; + + ret = __coherent_heap_register(rmem); + if (ret == -ENOMEM) + return coherent_heap_add_deferred(rmem); + return ret; +} + +static int __init coherent_heap_register_deferred(void) +{ + unsigned int i; + int ret; + + for (i = 0; i < rmem_areas_deferred_num; i++) { + struct reserved_mem *rmem = rmem_areas_deferred[i]; + + ret = __coherent_heap_register(rmem); + if (ret) { + pr_warn("Failed to add coherent heap %s", + rmem->name ? rmem->name : "unknown"); + continue; + } + } + + return 0; +} +late_initcall(coherent_heap_register_deferred); +MODULE_DESCRIPTION("DMA-BUF heap for coherent reserved-memory regions"); diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h index 648328a64b27e..e894cfa1ecf1a 100644 --- a/include/linux/dma-heap.h +++ b/include/linux/dma-heap.h @@ -9,9 +9,11 @@ #ifndef _DMA_HEAPS_H #define _DMA_HEAPS_H +#include <linux/errno.h> #include <linux/types.h> struct dma_heap; +struct reserved_mem; /** * struct dma_heap_ops - ops to operate on a given heap @@ -48,4 +50,13 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info); extern bool mem_accounting; +#if IS_ENABLED(CONFIG_DMABUF_HEAPS_COHERENT) +int dma_heap_coherent_register(struct reserved_mem *rmem); +#else +static inline int dma_heap_coherent_register(struct reserved_mem *rmem) +{ + return -EOPNOTSUPP; +} +#endif + #endif /* _DMA_HEAPS_H */ diff --git a/kernel/dma/coherent.c b/kernel/dma/coherent.c index 1147497bc512c..f49d13e460e4b 100644 --- a/kernel/dma/coherent.c +++ b/kernel/dma/coherent.c @@ -9,6 +9,7 @@ #include <linux/module.h> #include <linux/dma-direct.h> #include <linux/dma-map-ops.h> +#include <linux/dma-heap.h> struct dma_coherent_mem { void *virt_base; @@ -393,6 +394,14 @@ static int __init rmem_dma_setup(struct reserved_mem *rmem) rmem->ops = &rmem_dma_ops; pr_info("Reserved memory: created DMA memory pool at %pa, size %ld MiB\n", &rmem->base, (unsigned long)rmem->size / SZ_1M); + + if (IS_ENABLED(CONFIG_DMABUF_HEAPS_COHERENT)) { + int ret = dma_heap_coherent_register(rmem); + + if (ret) + pr_warn("Reserved memory: failed to register coherent heap for %s (%d)\n", + rmem->name ? rmem->name : "unknown", ret); + } return 0; } --- base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f change-id: 20260223-b4-dmabuf-heap-coherent-rmem-91fd3926afe9 Best regards, -- Albert Esteve <aesteve(a)redhat.com>

8 months

[PATCH v2 0/3] dma-buf: heaps: cma: enable dmem cgroup accounting

by Eric Chanudet

An earlier series[1] from Maxime introduced dmem to the cma allocator in an attempt to use it generally for dma-buf. Restart from there and apply the charge in the narrower context of the CMA dma-buf heap instead. In line with introducing cgroup to the system heap[2], this behavior is enabled based on dma_heap.mem_accounting, disabled by default. dmem is chosen for CMA heaps as it allows limits to be set for each region backing each heap. The charge is only put in the dma-buf heap for now as it guaranties it can be accounted against a userspace process that requested the allocation. [1] https://lore.kernel.org/all/20250310-dmem-cgroups-v1-0-2984c1bc9312@kernel.… [2] https://lore.kernel.org/all/20260116-dmabuf-heap-system-memcg-v3-0-ecc6b62c… Signed-off-by: Eric Chanudet <echanude(a)redhat.com> --- Changes in v2: - Rebase on Maxime's introduction of dmem to the cma allocator: https://lore.kernel.org/all/20250310-dmem-cgroups-v1-0-2984c1bc9312@kernel.… - Remove the dmem region registration from the cma dma-buf heap - Remove the misplaced logic for the default region. - Link to v1: https://lore.kernel.org/r/20260130-dmabuf-heap-cma-dmem-v1-1-3647ea993e99@r… --- Eric Chanudet (1): dma-buf: heaps: cma: charge each cma heap's dmem Maxime Ripard (2): cma: Register dmem region for each cma region cma: Provide accessor to cma dmem region drivers/dma-buf/heaps/cma_heap.c | 15 ++++++++++++++- include/linux/cma.h | 9 +++++++++ mm/cma.c | 20 +++++++++++++++++++- mm/cma.h | 3 +++ 4 files changed, 45 insertions(+), 2 deletions(-) --- base-commit: 948e195dfaa56e48eabda591f97630502ff7e27e change-id: 20260128-dmabuf-heap-cma-dmem-f4120a2df4a8 Best regards, -- Eric Chanudet <echanude(a)redhat.com>

8 months

[PATCH 0/7] dma-buf: heaps: Turn heaps into modules

by Maxime Ripard

Hi, The recent introduction of heaps in the optee driver [1] made possible the creation of heaps as modules. It's generally a good idea if possible, including for the already existing system and CMA heaps. The system one is pretty trivial, the CMA one is a bit more involved, especially since we have a call from kernel/dma/contiguous.c to the CMA heap code. This was solved by turning the logic around and making the CMA heap call into the contiguous DMA code. Let me know what you think, Maxime 1: https://lore.kernel.org/dri-devel/20250911135007.1275833-4-jens.wiklander@l… Signed-off-by: Maxime Ripard <mripard(a)kernel.org> --- Maxime Ripard (7): dma: contiguous: Turn heap registration logic around mm: cma: Export cma_alloc and cma_release mm: cma: Export cma_get_name mm: cma: Export dma_contiguous_default_area dma-buf: heaps: Export mem_accounting parameter dma-buf: heaps: cma: Turn the heap into a module dma-buf: heaps: system: Turn the heap into a module drivers/dma-buf/dma-heap.c | 1 + drivers/dma-buf/heaps/Kconfig | 4 ++-- drivers/dma-buf/heaps/cma_heap.c | 21 +++++---------------- drivers/dma-buf/heaps/system_heap.c | 5 +++++ include/linux/dma-map-ops.h | 5 +++++ kernel/dma/contiguous.c | 27 +++++++++++++++++++++++++-- mm/cma.c | 3 +++ 7 files changed, 46 insertions(+), 20 deletions(-) --- base-commit: 499a718536dc0e1c1d1b6211847207d58acd9916 change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a Best regards, -- Maxime Ripard <mripard(a)kernel.org>

8 months

[PATCH v2 0/2] dma-buf: heaps: system: add an option to allocate explicitly decrypted memory

by Jiri Pirko

From: Jiri Pirko <jiri(a)nvidia.com> Confidential computing (CoCo) VMs/guests, such as AMD SEV and Intel TDX, run with encrypted/protected memory which creates a challenge for devices that do not support DMA to it (no TDISP support). For kernel-only DMA operations, swiotlb bounce buffering provides a transparent solution by copying data through decrypted memory. However, the only way to get this memory into userspace is via the DMA API's dma_alloc_pages()/dma_mmap_pages() type interfaces which limits the use of the memory to a single DMA device, and is incompatible with pin_user_pages(). These limitations are particularly problematic for the RDMA subsystem which makes heavy use of pin_user_pages() and expects flexible memory usage between many different DMA devices. This patch series enables userspace to explicitly request decrypted (shared) memory allocations from the dma-buf system heap. Userspace can mmap this memory and pass the dma-buf fd to other existing importers such as RDMA or DRM devices to access the memory. The DMA API is improved to allow the dma heap exporter to DMA map the shared memory to each importing device. --- v1->v2: patch1: - rebased on top of recent dma-mapping-fixes patch2: - fixed build errors on s390 by including mem_encrypt.h - converted system heap flag implementation to a separate heap Based on dma-mapping-fixes HEAD d5b5e8149af0f5efed58653cbebf1cb3258ce49a Jiri Pirko (2): dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory dma-buf: heaps: system: add system_cc_decrypted heap for explicitly decrypted memory drivers/dma-buf/heaps/system_heap.c | 103 ++++++++++++++++++++++++++-- include/linux/dma-heap.h | 1 + include/linux/dma-mapping.h | 6 ++ include/trace/events/dma.h | 3 +- include/uapi/linux/dma-heap.h | 3 +- kernel/dma/direct.h | 14 +++- 6 files changed, 119 insertions(+), 11 deletions(-) -- 2.51.1

8 months

How to Recover Lost or Scammed Cryptocurrency, visit OPTIMISTIC HACKER GAIUS

by benjaminlucas0a＠gmail.com

OPTIMISTIC HACKER GAIUS is a professional crypto recovery service specializing in lost Bitcoin recovery, scammed USDT recovery, and digital asset tracing. The company uses advanced blockchain analysis and investigative techniques to track and recover stolen or inaccessible cryptocurrency. Known for clear communication and ethical practices, OPTIMISTIC HACKER GAIUS provides realistic assessments and reliable support for individuals and businesses affected by crypto-related losses. Mail-Box: support @ optimistichackargaius. c om WhatsApp: +44 737 674 0569 Website: optimistichackargaius. co m

8 months

Re: [RFC PATCH v4 0/2] RDMA/rxe: Add dma-buf support

by Zhu Yanjun

在 2021/11/22 3:08, Shunsuke Mie 写道: > This patch series add a dma-buf support for rxe driver. > > A dma-buf based memory registering has beed introduced to use the memory > region that lack of associated page structures (e.g. device memory and CMA > managed memory) [1]. However, to use the dma-buf based memory, each rdma > device drivers require add some implementation. The rxe driver has not > support yet. > > [1] https://www.spinics.net/lists/linux-rdma/msg98592.html > > To enable to use the dma-buf memory in rxe rdma device, add some changes > and implementation in this patch series. > > This series consists of two patches. The first patch changes the IB core > to support for rdma drivers that has not dma device. The secound patch adds > the dma-buf support to rxe driver. > Hi, Shunsuke Mie I was revisiting your 2021 proposal around dma-buf integration with RDMA and the related discussions at the time. As you know, dma-buf usage in RDMA-related workflows has gained more traction recently, and we are seeing increasing interest in heterogeneous memory and cross-device buffer sharing. Given the changes in the ecosystem since then, I’m wondering whether you think the original direction might be worth reconsidering. Do you have any interest in continuing that line of work, or updating the design based on today’s context? If not, I’d still appreciate your perspective on what you see as the main blockers from the previous discussions, and whether you think the landscape has changed enough to justify another attempt. Depending on the direction, we may consider exploring dma-buf support in rxe or at the core level, but I’d prefer to first understand your view before moving forward. Zhu Yanjun > Related user space RDMA library changes are provided as a separate patch. > > v4: > * Fix warnings, unused variable and casting > v3: https://www.spinics.net/lists/linux-rdma/msg106776.html > * Rebase to the latest linux-rdma 'for-next' branch (5.15.0-rc6+) > * Fix to use dma-buf-map helpers > v2: https://www.spinics.net/lists/linux-rdma/msg105928.html > * Rebase to the latest linux-rdma 'for-next' branch (5.15.0-rc1+) > * Instead of using a dummy dma_device to attach dma-buf, just store > dma-buf to use software RDMA driver > * Use dma-buf vmap() interface > * Check to pass tests of rdma-core > v1: https://www.spinics.net/lists/linux-rdma/msg105376.html > * The initial patch set > * Use ib_device as dma_device. > * Use dma-buf dynamic attach interface > * Add dma-buf support to rxe device > > Shunsuke Mie (2): > RDMA/umem: Change for rdma devices has not dma device > RDMA/rxe: Add dma-buf support > > drivers/infiniband/core/umem_dmabuf.c | 20 ++++- > drivers/infiniband/sw/rxe/rxe_loc.h | 2 + > drivers/infiniband/sw/rxe/rxe_mr.c | 113 ++++++++++++++++++++++++++ > drivers/infiniband/sw/rxe/rxe_verbs.c | 34 ++++++++ > include/rdma/ib_umem.h | 1 + > 5 files changed, 166 insertions(+), 4 deletions(-) >

8 months

Hire A Crypto Recovery Specialist; Recover Scammed Crypto With iForce Hacker Recovery

by aaronwycoff34＠gmail.com

Hello everyone, I wish to give my own review about iFORCE HACKER RECOVERY. I hope this message reaches the right audience. As an entrepreneur, I was eager to invest in cryptocurrency after learning about its potential to significantly increase my income. I came across someone online who promised exceptionally high returns, and because he seemed knowledgeable, I was easily convinced. After investing a substantial amount, I soon discovered that I was unable to withdraw my funds. It was all a scam. This left me in debt and caused severe damage to my business. Fortunately, I came across a pop-up about cryptocurrency recovery and cybersecurity experts. I reached out to iFORCE HACKER RECOVERY, a cybersecurity and cryptocurrency recovery company, and they successfully helped me recover my lost funds. I am incredibly grateful for their services and highly recommend them to anyone in need of cryptocurrency recovery assistance. Website; ht tps: //iforcehackers. co m/ Email; iforcehk @ consultant. c om Call/Text-whatsapp; +1 (240) 8033 (706)

8 months

TOP 4 BEST GOOD CRYPTOCURRENCY RECOVERY SPECIALIST FOR LEGITIMATE CRYPTO RECOVERY IN 2026

by angelaasher62＠gmail.com

In 2026, cryptocurrency theft, scams, and accidental loss remain among the most common forms of digital financial harm. Phishing pages that clone Ledger or MetaMask interfaces, AI deepfake “support” calls, fake staking/yield platforms displaying fabricated profits, romance-to-crypto investment traps, wallet-draining malware, and unauthorized seed-phrase compromises continue to drain billions from users worldwide. When the funds disappear, the natural instinct is to search for “crypto recovery service” — only to discover that most results are secondary scams designed to exploit victims a second time. So should you hire a crypto recovery service? The expert consensus is clear: only if the service is genuinely legitimate, technically competent, transparent, and realistic. Hiring the wrong one almost always costs you more money and gives you zero chance of recovery. Hiring the right one significantly improves your realistic odds when funds are still traceable. When Hiring a Recovery Service Makes Sense Expert insight: Recovery is most viable in these scenarios: Funds recently sent to a scammer (within hours to a few days) The sooner you act, the less time scammers have to launder through mixers, cross-chain bridges, privacy protocols, or non-KYC off-ramps. Funds landed on a KYC/AML-compliant centralized exchange Regulated platforms (especially those operating in or serving U.S./EU jurisdictions) can freeze assets or cooperate with documented victims when presented with strong evidence. You have strong, complete evidence Multiple transaction IDs (TXIDs), sending/receiving addresses, scam messages/screenshots, deposit records, timelines, and communication logs dramatically increase traceability. Wallet access issue (not outright theft) Forgotten passwords, damaged hardware, or malware-compromised wallets can often be restored using secure, non-destructive professional methods. If your case matches one or more of these, hiring a reputable recovery service is often the smartest and most effective step you can take. When Hiring a Recovery Service Is Unlikely to Help Expert insight: Be realistic about low-success scenarios: Funds already laundered through multiple mixers/privacy coins and off-ramped to fiat Very small amounts (below most services’ minimum viable case threshold) No preserved evidence (missing TXIDs, screenshots, or communication logs) Loss occurred months or years ago with no traceable endpoints remaining In these situations, even the best legitimate service may conclude recovery is not feasible. Ethical experts will tell you this upfront — scammers will promise success anyway. How to Identify a Legitimate Recovery Service in 2026 The single most important decision is choosing the right provider. Here are the non-negotiable markers of legitimacy: Free, no-obligation initial case evaluation Never requests private keys, seed phrases, wallet access, or login credentials No large upfront fees before detailed feasibility review Uses only professional website + secure email (no Telegram/WhatsApp/DMs/forums as primary contact) Provides realistic success projections (no “100% guaranteed” or “instant recovery” claims) Delivers regular encrypted progress updates Focuses on blockchain forensics, exchange coordination, and documentation — not “magic hacks” Autopsy Mainnet Recovery (AMR) consistently meets every one of these criteria and is widely regarded as one of the most reputable and effective legitimate recovery services operating in 2026. Expert Insights from Autopsy Mainnet Recovery (AMR) Autopsy Mainnet Recovery (AMR), accessible only through their verified official platform at pucnonline.com, is frequently cited by scam victims and industry observers as a top-tier choice for several key reasons: Elite forensic capability — Advanced multi-chain tracing that maps funds even through complex laundering paths Endpoint intelligence — Strong focus on identifying when stolen assets reach compliant centralized exchanges Scam-specific expertise — Deep knowledge of 2026-era fraud vectors: phishing, fake yield platforms, deepfake impersonations, romance-to-crypto fraud Victim-first transparency — Free evaluations, detailed reports, no sensitive data requests, regular updates, realistic expectations Secure & ethical process — Official channels only ( https://autospyrec.site and info(a)autopsymainnetsolutions.com ), strict confidentiality, post-recovery security guidance Autopsy Mainnet Recovery (AMR)’s experts emphasize that speed + evidence + legitimate professional help is the formula that produces the highest realistic success rates. Final Expert Recommendation Should you hire a crypto recovery service? Yes — if you choose a legitimate one and act quickly. Hiring a reputable provider like Autopsy Mainnet Recovery (AMR) significantly improves your chances when funds remain traceable, while also protecting you from secondary scams that would only deepen your losses. If you’ve lost crypto assets: Preserve every piece of evidence immediately Secure remaining holdings in a new hardware wallet File official reports (IC3.gov, ReportFraud.ftc.gov, etc.) Contact only verified official channels for a free evaluation Visit https://www.autopsymainnetsolutions.com or email info(a)autopsymainnetsolutions.com today for a confidential consultation. Never pay upfront fees without a detailed review. Never share sensitive wallet information. Never trust unsolicited offers. Recovery is difficult and never guaranteed, but the right legitimate service gives you the strongest realistic opportunity to reclaim what was stolen in today’s challenging environment. Stay vigilant, verify everything, and protect your digital future.

8 months

[PATCH rdma-next v3 0/3] RDMA: Add support for exporting dma-buf file descriptors

by Edward Srouji

This patch series introduces dma-buf export support for RDMA/InfiniBand devices, enabling userspace applications to export RDMA PCI-backed memory regions (such as device memory or mlx5 UAR pages) as dma-buf file descriptors. This allows PCI device memory to be shared with other kernel subsystems (e.g., graphics or media) or between userspace processes, via the standard dma-buf interface, avoiding unnecessary copies and enabling efficient peer-to-peer (P2P) DMA transfers. See [1] for background on dma-buf. As part of this series, we introduce a new uverbs object of type FD for dma-buf export, along with the corresponding APIs for allocation and teardown. This object encapsulates all attributes required to export a dma-buf. The implementation enforces P2P-only mappings and properly manages resource lifecycle, including: - Cleanup during driver removal or RDMA context destruction. - Revocation via dma_buf_move_notify() when the underlying mmap entries are removed. - Refactors common cleanup logic for reuse across FD uobject types. The infrastructure is generic within uverbs, allowing individual drivers to easily integrate and supply their vendor-specific implementation. The mlx5 driver is the first consumer of this new API, providing: - Initialization of PCI peer-to-peer DMA support. - mlx5-specific implementations of the mmap_get_pfns and pgoff_to_mmap_entry device operations required for dma-buf export. [1] https://docs.kernel.org/driver-api/dma-buf.html Signed-off-by: Yishai Hadas <yishaih(a)nvidia.com> Signed-off-by: Edward Srouji <edwards(a)nvidia.com> --- Changes in v3: - Wait for importers to complete their unmap() calls after dma_buf_move_notify(), ensuring all mappings are properly cleaned up before revocation - Add unpin callback to pair with pin (both are required by dma-buf ops) - Link to v2: https://lore.kernel.org/r/20260121-dmabuf-export-v2-0-6381183bcc3d@nvidia.c… Changes in v2: - Split the FD uobject refactoring into a separate patch ("RDMA: Add support for exporting dma-buf file descriptors") - Remove redundant revoked check from attach callback. It is checked during map - Add pin callback that returns -EOPNOTSUPP to explicitly refuse pinned importers - Wait for pending fences after dma_buf_move_notify() using dma_resv_wait_timeout() to ensure hardware has completed all in-flight operations before proceeding - Link to v1: https://lore.kernel.org/r/20260108-dmabuf-export-v1-0-6d47d46580d3@nvidia.c… --- Yishai Hadas (3): RDMA/uverbs: Support external FD uobjects RDMA/uverbs: Add DMABUF object type and operations RDMA/mlx5: Implement DMABUF export ops drivers/infiniband/core/Makefile | 1 + drivers/infiniband/core/device.c | 2 + drivers/infiniband/core/ib_core_uverbs.c | 24 +++ drivers/infiniband/core/rdma_core.c | 63 ++++--- drivers/infiniband/core/rdma_core.h | 1 + drivers/infiniband/core/uverbs.h | 21 +++ drivers/infiniband/core/uverbs_std_types_dmabuf.c | 200 ++++++++++++++++++++++ drivers/infiniband/core/uverbs_uapi.c | 1 + drivers/infiniband/hw/mlx5/main.c | 72 ++++++++ include/rdma/ib_verbs.h | 9 + include/rdma/uverbs_types.h | 1 + include/uapi/rdma/ib_user_ioctl_cmds.h | 10 ++ 12 files changed, 379 insertions(+), 26 deletions(-) --- base-commit: 325e3b5431ddd27c5f93156b36838a351e3b2f72 change-id: 20260108-dmabuf-export-0d598058dd1e Best regards, -- Edward Srouji <edwards(a)nvidia.com>

8 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig