Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

24 participants
3679 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

8 months

[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, 1 week

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, 1 week

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, 1 week

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, 1 week

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, 1 week

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig