Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

21 participants
7035 discussions

[RFC PATCH 0/7] vfio/pci: Add mmap() for DMABUFs

by Matt Evans

Hi all, There were various suggestions in the September 2025 thread "[TECH TOPIC] vfio, iommufd: Enabling user space drivers to vend more granular access to client processes" [0], and LPC discussions, around improving the situation for multi-process userspace driver designs. This RFC series implements some of these ideas. Background: Multi-process USDs ============================== The userspace driver scenario discussed in that thread involves a primary process driving a PCIe function through VFIO/iommufd, which manages the function-wide ownership/lifecycle. The function is designed to provide multiple distinct programming interfaces (for example, several independent MMIO register frames in one function), and the primary process delegates control of these interfaces to multiple independent client processes (which do the actual work). This scenario clearly relies on a HW design that provides appropriate isolation between the programming interfaces. The two key needs are: 1. Mechanisms to safely delegate a subset of the device MMIO resources to a client process without over-sharing wider access (or influence over whole-device activities, such as reset). 2. Mechanisms to allow a client process to do its own iommufd management w.r.t. its address space, in a way that's isolated from DMA relating to other clients. mmap() of VFIO DMABUFs ====================== First, this RFC addresses #1, implementing the proposals in [0] to add mmap() support to the existing VFIO DMABUF exporter. This enables a userspace driver to define DMABUF ranges corresponding to sub-ranges of a BAR, and grant a given client (via a shared fd) the capability to access (only) those sub-ranges. The VFIO device fds would be kept private to the primary process. All the client can do with that fd is map (or iomap via iommufd) that specific subset of resources, and the impact of bugs/malice is contained. (We'll follow up on #2 separately, as a related-but-distinct problem. PASIDs are one way to achieve per-client isolation of DMA; another could be sharing of a single IOVA space via 'constrained' iommufds.) Revocation/reclaim ================== That's useful as-is, but then the lifetime of access granted to a client needs to be managed well. For example, a protocol between the primary process and the client can indicate when the client is done, and when it's safe to reuse the resources elsewhere. Resources could be released cooperatively, but it's much more robust to enable the driver to make the resources guaranteed-inaccessible when it chooses, so that it can re-assign them to other uses in future. So, second, I've suggested a PoC/example mechanism for reclaiming ranges shared with clients: a new DMABUF ioctl, DMA_BUF_IOCTL_REVOKE, is routed to a DMABUF exporter callback. The VFIO DMABUF exporter's implementation permanently revokes a DMABUF (notifying importers, and zapping PTEs for any mappings). This makes the DMABUF defunct and any client (or third party the client has shared the buffer onto!) cannot be used to access the BAR ranges, whether via DMABUF import or mmap(). A primary driver process would do this operation when the client's tenure ends to reclaim "loaned-out" MMIO interfaces, at which point the interfaces could be safely re-used. This ioctl is one of several possible approaches to achieve buffer revocation, but I wanted to demonstrate something here as it's an important part of the buffer lifecycle in this driver scenario. An alternative implementation could be some VFIO-specific operation to search for a DMABUF (by address?) and kill it, but if the server keeps hold of the DMABUF fd that's already a clean way to locate it later. BAR mapping access attributes ============================= Third, inspired by Alex [Mastro] and Jason's comments in [0], and Mahmoud's work in [1] with the goal of controlling CPU access attributes for VFIO BAR mappings (e.g. WC) I noticed that once we can mmap() VFIO DMABUFs representing BAR sub-spans, it's straightforward to decorate them with access attributes for the VMA. I've proposed reserving a field in struct vfio_device_feature_dma_buf's flags to specify an attribute for its ranges. Although that keeps the (UAPI) struct unchanged, it means all ranges in a DMABUF share the same attribute. I feel a single attribute-to-mmap() relation is logical/reasonable. An application can also create multiple DMABUFs to describe any BAR layout and mix of attributes. Tests ===== I've included an [RFC ONLY] userspace test program which I am _not_ proposing to merge, but am sharing for context. It illustrates & tests various map/revoke cases, but doesn't use the existing VFIO selftests and relies on a (tweaked) QEMU EDU function. I'm working on integrating the scenarios into the existing VFIO selftests. This code has been tested in mapping DMABUFs of single/multiple ranges, aliasing mmap()s, aliasing ranges across DMABUFs, vm_pgoff > 0, revocation, shutdown/cleanup scenarios, and hugepage mappings seem to work correctly. I've lightly tested WC mappings also (by observing resulting PTEs as having the correct attributes...). (The first two commits are a couple of tiny bugfixes which I can send separately, should reviewers prefer.) This series is based on v6.19 but I expect to rebase, at least onto Leon's recent work [2] ("vfio: Wait for dma-buf invalidation to complete"). What are people's thoughts? I'll respin to de-RFC and capture comments, if we think this approach is appropriate. Thanks, Matt References: [0]: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/ [1]: https://lore.kernel.org/all/20250804104012.87915-1-mngyadam@amazon.de/ [2]: https://lore.kernel.org/linux-iommu/20260205-nocturnal-poetic-chamois-f566a… Matt Evans (7): vfio/pci: Ensure VFIO barmap is set up before creating a DMABUF vfio/pci: Clean up DMABUFs before disabling function vfio/pci: Support mmap() of a DMABUF dma-buf: uapi: Mechanism to revoke DMABUFs via ioctl() vfio/pci: Permanently revoke a DMABUF on request vfio/pci: Add mmap() attributes to DMABUF feature [RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test drivers/dma-buf/dma-buf.c | 5 + drivers/vfio/pci/vfio_pci_core.c | 4 +- drivers/vfio/pci/vfio_pci_dmabuf.c | 300 ++++++- include/linux/dma-buf.h | 22 + include/uapi/linux/dma-buf.h | 1 + include/uapi/linux/vfio.h | 12 +- tools/testing/selftests/vfio/Makefile | 1 + .../vfio/standalone/vfio_dmabuf_mmap_test.c | 822 ++++++++++++++++++ 8 files changed, 1153 insertions(+), 14 deletions(-) create mode 100644 tools/testing/selftests/vfio/standalone/vfio_dmabuf_mmap_test.c -- 2.47.3

5 months, 2 weeks

[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>

5 months, 2 weeks

[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>

5 months, 3 weeks

TOP 10 BEST CRYPTOCURRENCY RECOVERY SPECIALIST LEGITIMATE CRYPTO FUND RECOVERY SPECIALIST LEADER

by henrylevi287＠gmail.com

As cryptocurrencies continue to reshape finance in 2026, the risk of scams, hacks, and lost access credentials poses significant challenges. Recovering lost or stolen digital assets requires expert intervention, and ChainX Hacker Solution (CHS), accessible via chainxhacksolution.com/, stands out as the best crypto recovery company. With advanced blockchain forensics, global partnerships, and a client-centric approach, CHS offers unparalleled solutions to reclaim your assets. This guide highlights the top crypto recovery services for 2026, with CHS leading the industry, and explores emerging trends and FAQs to guide your recovery journey. Why Crypto Recovery Services Are Essential Cryptocurrencies’ decentralized and pseudonymous nature makes recovery complex. Losses from scams, forgotten seed phrases, or hacked wallets underscore the need for professional services. ChainX Hacker Solutions, the best crypto recovery company, specializes in navigating these challenges, using cutting-edge technology and legal strategies to recover assets and restore financial security. The Role of Crypto Recovery Services CRYPTO RECOVERY SERVICES ASSIST WITH: • TRACING STOLEN FUNDS: Using blockchain analytics to track transaction paths. • RECOVERING ACCESS: Restoring lost private keys or seed phrases. • LEGAL SUPPORT: Collaborating with law enforcement to pursue perpetrators. • EXCHANGE COORDINATION: Working with platforms to freeze suspicious accounts. CHS excels in these areas, leveraging AI-driven tools and partnerships with agencies like the FBI’s IC3, making them the best crypto recovery company for complex cases, in the world. Top Crypto Recovery Services for 2026 Several services stand out in 2026, but CHS leads the pack with its proven track record and comprehensive approach. ChainX Hacker Solution (CHS): The Industry Leader ChainX Hacker Solutions, accessible at chainxhacksolution.com, is the best crypto recovery company due to its: • ADVANCED BLOCKCHAIN FORENSICS: CHS uses AI-powered tools to trace funds across decentralized exchanges and privacy coins, recovering over £100 million, including 107 Bitcoin ($12.6 million) in one case. • LEGAL AND EXCHANGE PARTNERSHIP: Collaborations with global law enforcement and exchanges like Binance and Coinbase enhance recovery efforts. • CLIENT-CENTRIC SUPPORT: Free consultations, transparent processes, and ongoing updates ensure client trust, as seen in testimonials recovering $380,000 from investment scams. • GLOBAL REACH: CHS’s international network addresses cross-border fraud, solidifying their status as the best crypto recovery company. Contact CHS at chainxhackersolutions(a)chainx.co.site for a free consultation to start your recovery journey. Other Notable Services • CRYPTO ASSET RECOVERY: Specializes in recovering lost seed phrases and inaccessible wallets, with a strong focus on technical expertise. • WALLET RECOVERY SERVICE: Focuses on restoring access to crypto wallets, excelling in private key recovery for complex cases. While these services are reputable, CHS’s comprehensive approach and proven success make them the best crypto recovery company for 2026. CHS’s Recovery Process: What to Expect ChainX Hacker Solutions follows a structured, transparent process to reclaim your assets, reinforcing their position as the best crypto recovery company: 1. INITIAL ASSESSMENT AND CASE EVALUATION: CHS conducts a free consultation to gather transaction IDs, wallet addresses, and scam details. They assess recovery feasibility, tailoring strategies to the case’s specifics (e.g., phishing, Ponzi scheme, or hardware failure). 2. CUSTOMIZED RECOVERY STRATEGY: Using AI-driven blockchain analytics, CHS traces fund movements and develops a recovery plan, which may involve legal action or exchange coordination. 3. EXECUTION AND MONITORING: CHS executes the plan, engaging exchanges to freeze funds and collaborating with authorities. Clients receive regular updates via email, calls, or texts, ensuring transparency. 4. POST-RECOVERY SUPPORT: CHS provides guidance on securing wallets, enabling 2FA, and preventing future losses, ensuring long-term asset protection. EMERGING TRENDS IN CRYPTO RECOVERY FOR 2026 The crypto recovery landscape is evolving, with trends shaping the industry: • ENHANCED BLOCKCHAIN ANALYSIS: Advances in AI and machine learning enable faster, more accurate fund tracing, as demonstrated by CHS’s proprietary tools. • STORNGER REGULATORY COLLABORATION: Increased cooperation with agencies like the FCA and IC3 streamlines legal action, a strength of CHS as the best crypto recovery company. • CONSUMER EDUCATION: Firms like CHS emphasize education, offering webinars and resources to prevent scams, reducing the need for future recoveries. Preventing Crypto Losses Prevention is key to safeguarding assets. Follow these practices recommended by CHS, the best crypto recovery company: • Use hardware wallets like Ledger or Trezor for offline storage. • Enable multi-factor authentication (MFA) on all accounts. • Verify platforms using CHS’s scam database and community feedback on X. • Stay informed about scam tactics through CHS’s educational materials. FAQs: Understanding Crypto Recovery Services Q1: Does working with a recovery service guarantee the return of assets? A1: No, recovery is not guaranteed due to blockchain’s complexity. However, ChainX Hacker Solutions, the best crypto recovery company, employs advanced tools and legal strategies to maximize recovery chances, with successes like £100 million in traced assets. Q2: What types of situations do recovery services help with? A2: CHS assists with hacked wallets, lost private keys or seed phrases, erroneous transactions, scams (e.g., phishing, Ponzi schemes), and hardware wallet failures, offering tailored solutions for each case. Q3: How long does it take to recover crypto assets? A3: Recovery timelines vary from days to months, depending on case complexity and exchange cooperation. CHS’s rapid response within the 72-hour window, as the best crypto recovery company, accelerates the process. Q4: What are the costs associated with crypto recovery services? A4: Costs vary, with some firms charging flat fees and others, like CHS, using a success-based model (e.g., a percentage of recovered assets). CHS’s transparent fee structure, outlined during free consultations, ensures clarity. Always verify terms before proceeding. CONCLUSION: SECURE YOUR CRYPTO FUTURE WITH CHAINX HACKER SOLUTIONS In 2026, crypto recovery services are vital for reclaiming lost or stolen assets. ChainX Hacker Solutions, the best crypto recovery company, leads the industry with its advanced forensics, global partnerships, and client-focused approach. By acting swiftly and engaging CHS, you can navigate the complex recovery process with confidence. Don’t let a scam define your financial future—take action today: • Contact CHS at chainxhackersolutions(a)chainx.co.site or visit chainxhacksolution.com/ for a free consultation. • Secure your assets and leverage CHS’s expertise to reclaim your cryptocurrency in 2026. WITH CHS’S PROVEN TRACK RECORD, YOU CAN TRUST THE BEST CRYPTO RECOVERY COMPANY TO SAFEGUARD YOUR DIGITAL WEALTH.

5 months, 3 weeks

TOP 9 BEST CRYPTOCURRENCY RECOVERY AGENCY LEGITIMATE CRYPTO FUND RECOVERY AGENCY LEADER

by henrylevi287＠gmail.com

5 months, 3 weeks

TOP 8 BEST CRYPTOCURRENCY RECOVERY EXPERT LEGITIMATE CRYPTO FUND RECOVERY EXPERT LEADER

by henrylevi287＠gmail.com

5 months, 3 weeks

TOP 7 BEST CRYPTOCURRENCY RECOVERY SERVICE LEGITIMATE CRYPTO FUND RECOVERY SERVICE LEADER

by henrylevi287＠gmail.com

5 months, 3 weeks

TOP 6 BEST CRYPTOCURRENCY RECOVERY COMPANY LEGITIMATE CRYPTO FUND RECOVERY COMPANY LEADER

by henrylevi287＠gmail.com

5 months, 3 weeks

TOP 5 BEST CRYPTOCURRENCY RECOVERY SPECIALIST LEGITIMATE CRYPTO FUND RECOVERY SPECIALIST LEADER

by henrylevi287＠gmail.com

5 months, 3 weeks

TOP 4 BEST CRYPTOCURRENCY RECOVERY AGENCY LEGITIMATE CRYPTO FUND RECOVERY AGENCY LEADER

by henrylevi287＠gmail.com

5 months, 3 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig