Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

25 participants
5332 discussions

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

by Albert Esteve

Hi Maxime! On Thu, Feb 26, 2026 at 11:12 AM Maxime Ripard <mripard(a)redhat.com> wrote: > > Hi Albert, > > Thanks for your patch! > > On Tue, Feb 24, 2026 at 08:57:33AM +0100, Albert Esteve wrote: > > 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 > > I'm not sure we need to make it configurable. Distros are going to set > it to the user with the highest number of regions anyway. How about > using MAX_RESERVED_REGIONS for now? Makes sense, will do. > > > > > [...] > > > > +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 > > We might want to leave the dmem accounting out for now so we can focus > on the heap itself. That being said, it ended up being pretty trivial > for CMA, so maybe it's not too much of a concern. Sure. That allows us to follow the same patterns once the CMA series lands. I will strip all dmem accounting parts for v2. > > > > > [...] > > > > +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"; > > If the reserved region has no name, we probably shouldn't expose it to > userspace at all. Using unknown will probably create some bugs if you > have several, but also it's pretty like to have a name at some point and > thus we wouldn't have a stable name for the uAPI. Agreed. I will return an error code if no name is present. > > > + 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; > > + } > > Similarly, we shouldn't use the coherent_ prefix for the heap name. If > the backing allocator ever changes (and between contiguous and coherent, > the difference is just a single property value in the DT), then the name > would change and userspace would break. We should directly use the name > of the region here. > > > + 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; > > + } > > We probably should use a faux_device here instead of a platform_device, > but more importantly, the heap itself already has a device allocated for > it (dev_ret in dma_heap_add). > > It's not in struct dma_heap yet, but there's a patch that moves it there > that we should probably carry: > https://lore.kernel.org/r/20210120210937.15069-2-john.stultz@linaro.org/ Thanks for sharing the link! I will pick the patch. > > > + if (rmem->ops && rmem->ops->device_init) { > > + ret = rmem->ops->device_init(rmem, &coh_heap->pdev->dev); > > + if (ret) > > + goto pdev_unregister; > > + } > > I'm not really a fan of calling ops directly. Maybe we should create an > of_reserved_mem_device_init_with_mem function that would do it for us > (and would be called by of_reserved_mem_device_init_by_idx and the > likes). Agreed. > > > + 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 > > Same comment than for CMA here: it should really be created by the > coherent memory region itself. > > > + 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; > > +} > > I appreciate you did it like we did for CMA, but if we ever want to make > that heap a module you'll end up with a dependency from the core kernel > on a module which doesn't work. The best here might be to wait a bit > until we have somewhat of an agreement on > > https://lore.kernel.org/r/20260225-dma-buf-heaps-as-modules-v1-0-2109225a09… > > > +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); > > Why do you need a late_initcall here? Isn't module_init enough? When I tested this initially, I relied on direct invocations from cma/coherent.c to register new coherent heap areas. However it failed in `kzalloc_obj` calls within the register function. Then I read the article about boot time memory management[1] and saw other drivers collected info for deferred initialization at late_initcall(), similar to what I tried to do here. I honestly did not try with module_init(). Since I will refactor this part to follow your previous comments, I will try to update if possible. [1] https://docs.kernel.org/core-api/boot-time-mm.html > > > +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); > > + } > > I think this should be split into a patch of its own. It's going to be > reviewed (and possibly merged) by another maintainer, through another > tree. That's fine. I will split it into another series then. I guess I can send it with a Based-On: tag or similar to link two series together? BR, Albert > > Maxime

9 minutes

[PATCH v2 0/9] 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> --- Changes in v2: - Collect tags - Don't export dma_contiguous_default_area anymore, but export dev_get_cma_area instead - Mentioned that heap modules can't be removed - Link to v1: https://lore.kernel.org/r/20260225-dma-buf-heaps-as-modules-v1-0-2109225a09… --- Maxime Ripard (9): dma: contiguous: Turn heap registration logic around dma: contiguous: Make dev_get_cma_area() a proper function dma: contiguous: Make dma_contiguous_default_area static mm: cma: Export dev_get_cma_area() mm: cma: Export cma_alloc and cma_release mm: cma: Export cma_get_name 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 | 14 ++++++-------- kernel/dma/contiguous.c | 37 ++++++++++++++++++++++++++++++++++--- mm/cma.c | 3 +++ 7 files changed, 56 insertions(+), 29 deletions(-) --- base-commit: 499a718536dc0e1c1d1b6211847207d58acd9916 change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a Best regards, -- Maxime Ripard <mripard(a)kernel.org>

18 minutes

RECOVER LOST INVESTMENT:THROUGH CHAINTRACE ASSET RECOVERY

by mikelowrey090＠gmail.com

I am thrilled to share my positive experience with CHAINTRACE ASSET RECOVERY, a reputable firm that specializes in recovering lost or scammed cryptocurrencies. Unfortunately, I fell victim to a sophisticated scam, which resulted in the loss of my bitcoin. I had sent the funds to a scammer's wallet address, thinking I was making a legitimate transaction. However, it soon became apparent that I had been deceived. Devastated and feeling helpless, I began to research possible solutions to recover my stolen bitcoin. That's when I came across CHAINTRACE ASSET RECOVERY. I was skeptical at first, but after reading numerous testimonials and reviews from satisfied clients, I decided to reach out to them for assistance. The team at CHAINTRACE ASSET RECOVERY was professional, responsive, and empathetic. They guided me through the recovery process, which was surprisingly efficient and straightforward. Their expertise and knowledge of blockchain technology and cryptocurrency transactions were impressive, and I was confident that I was in good hands. Thanks to CHAINTRACE ASSET RECOVERY, I was able to recover a significant portion of my lost bitcoin. I am extremely grateful for their help and would highly recommend their services to anyone who has fallen victim to cryptocurrency scams. If you have lost your crypto to scammers, I urge you to contact CHAINTRACE ASSET RECOVERY. Their dedication to helping individuals recover their stolen assets is truly commendable, and I am thankful to have found them. In conclusion, my experience with CHAINTRACE ASSET RECOVERY has been nothing short of exceptional. Their professionalism, expertise, and commitment to recovering lost cryptocurrencies have made a significant difference in my life. If you are a victim of cryptocurrency scams, do not lose hope. Reach out to CHAINTRACE ASSET RECOVERY, and let their team of experts help you recover your stolen assets. WHATSAPP : +1 (581) 256‑1989 EMAIL: chaintraceasset(a)post.com WEBSITE: ‪https://chaintraceassetrecovery.com

8 hours, 7 minutes

Lost Recovery Services

by pierrebeatrice468＠gmail.com

If you've lost access to your Bitcoin or other cryptocurrencies, ALMIGHTY RECOVERY can help. Their team employs proven methods to recover lost funds, providing support through every step of the process. This service is crucial for those who may have forgotten passwords or lost recovery keys. Email,.. almightyrecoverycoin(@) mail . (com) WhatsApp,.. +53 5 (155) 6969 Website,.. almightyrecoveryco.wixsite.com/almighty-recovery-co

11 hours, 41 minutes

TRUSTED EXPERTS ONLINE RECOVERY SOLUTIONS//ALMIGHTY RECOVERY COIN

by Jeremy Thorgan

Almighty Cryptocurrency Recovery is a private investigation, asset recovery, and financial regulator. We specialize in instances involving recovery scams, cryptocurrency, fake investment schemes, and ethical hacking. We examine the factors influencing your score and are also experts in credit repair. removing criminal records, school grades, and jobs involving phone and social media hacking. Every piece of software required to carry out recoveries from beginning to end is available. The writers and offenders band together to establish a syndicate, so be wary of false reviews and testimonials on the internet.To get started, send an email to our support team at the address below as soon as you can. almightyrecoverycoin(a)mail.com and whatsapp +53 51 55 6969 Visit website; almightyrecoveryco.wixsite.com/almighty-recovery-co Stay Safe!

11 hours, 42 minutes

[PATCH 0/5] Replace the dmabuf custom test framework with kunit

by Jason Gunthorpe

Using kunit to write tests for new work on dmabuf is coming up: https://lore.kernel.org/all/26-v1-b5cab63049c0+191af-dmabuf_map_type_jgg@nv… Replace the custom test framework with kunit to avoid maintaining two concurrent test frameworks. The conversion minimizes code changes and uses simple pattern-oriented reworks to reduce the chance of breaking any tests. Aside from adding the kunit_test_suite() boilerplate, the conversion follows a number of patterns: Test failures without cleanup. For example: if (!ptr) return -ENOMEM; Becomes: KUNIT_ASSERT_NOT_NULL(test, ptr); In kunit ASSERT longjumps out of the test. Check for error, fail and cleanup: if (err) { pr_err("msg\n"); goto cleanup; } Becomes: if (err) { KUNIT_FAIL(test, "msg"); goto cleanup; } Preserve the existing failure messages and cleanup code. Cases where the test returns err but prints no message: if (err) goto cleanup; Becomes: if (err) { KUNIT_FAIL(test, "msg"); goto cleanup; } Use KUNIT_FAIL to retain the 'cleanup on err' behavior. Overall, the conversion is straightforward. The result can be run with kunit.py: $ tools/testing/kunit/kunit.py run --build_dir build_kunit_x86_64 --arch x86_64 --kunitconfig ./drivers/dma-buf/.kunitconfig [20:37:23] Configuring KUnit Kernel ... [20:37:23] Building KUnit Kernel ... Populating config with: $ make ARCH=x86_64 O=build_kunit_x86_64 olddefconfig Building with: $ make all compile_commands.json scripts_gdb ARCH=x86_64 O=build_kunit_x86_64 --jobs=20 [20:37:29] Starting KUnit Kernel (1/1)... [20:37:29] ============================================================ Running tests with: $ qemu-system-x86_64 -nodefaults -m 1024 -kernel build_kunit_x86_64/arch/x86/boot/bzImage -append 'kunit.enable=1 console=ttyS0 kunit_shutdown=reboot' -no-reboot -nographic -accel kvm -accel hvf -accel tcg -serial stdio -bios qboot.rom [20:37:30] ================ dma-buf-resv (5 subtests) ================= [20:37:30] [PASSED] test_sanitycheck [20:37:30] ===================== test_signaling ====================== [20:37:30] [PASSED] kernel [20:37:30] [PASSED] write [20:37:30] [PASSED] read [20:37:30] [PASSED] bookkeep [20:37:30] ================= [PASSED] test_signaling ================== ... [20:37:35] Testing complete. Ran 50 tests: passed: 49, skipped: 1 [20:37:35] Elapsed time: 12.635s total, 0.001s configuring, 6.551s building, 6.017s running One test that requires two CPUs is skipped since the default VM has a single CPU and cannot run the test. All other usual ways to run kunit work as well, and all tests are placed in a module to provide more options for how they are run. AI was used to do the large scale semantic search and replaces described above, then everything was hand checked. AI also deduced the issue with test_race_signal_callback() in a couple of seconds from the kunit crash (!!), again was hand checked though I am not so familiar with this test to be fully certain this is the best answer. Jason Gunthorpe (5): dma-buf: Change st-dma-resv.c to use kunit dma-buf: Change st-dma-fence.c to use kunit dma-buf: Change st-dma-fence-unwrap.c to use kunit dma-buf: Change st-dma-fence-chain.c to use kunit dma-buf: Remove the old selftest drivers/dma-buf/.kunitconfig | 2 + drivers/dma-buf/Kconfig | 11 +- drivers/dma-buf/Makefile | 5 +- drivers/dma-buf/selftest.c | 167 --------------- drivers/dma-buf/selftest.h | 30 --- drivers/dma-buf/selftests.h | 16 -- drivers/dma-buf/st-dma-fence-chain.c | 217 +++++++++---------- drivers/dma-buf/st-dma-fence-unwrap.c | 290 +++++++++++--------------- drivers/dma-buf/st-dma-fence.c | 200 ++++++++---------- drivers/dma-buf/st-dma-resv.c | 145 +++++++------ drivers/gpu/drm/i915/Kconfig.debug | 2 +- 11 files changed, 394 insertions(+), 691 deletions(-) create mode 100644 drivers/dma-buf/.kunitconfig delete mode 100644 drivers/dma-buf/selftest.c delete mode 100644 drivers/dma-buf/selftest.h delete mode 100644 drivers/dma-buf/selftests.h base-commit: 41dae5ac5e157b0bb260f381eb3df2f4a4610205 -- 2.43.0

18 hours, 49 minutes

Re: [RFC PATCH 3/7] vfio/pci: Support mmap() of a DMABUF

by Jason Gunthorpe

On Fri, Feb 27, 2026 at 01:52:15PM -0800, Alex Mastro wrote: > On Fri, Feb 27, 2026 at 03:48:07PM -0400, Jason Gunthorpe wrote: > > > > I actually would like to go the other way and have VFIO always have a > > > > DMABUF under the VMA's it mmaps because that will make it easy to > > > > finish the type1 emulation which requires finding dmabufs for the > > > > VMAs. > > > > This is a still better idea since it avoid duplicating the VMA flow > > into two parts.. > > I suppose this would also compose with your idea to use dma-buf for > iommufd_compat support of VFIO_IOMMU_MAP_DMA of vfio device fd-backed mmap()s > [1]? Instead of needing to materialize a new dma-buf, you could use the existing > backing one? Yeah, that too I think it is a fairly easy progression: 1) mmap_prepare() allocates a new dmabuf file * and sticks it in desc->vm_file. Rework so all the vma_ops are using vm_file that is a dmabuf. The allocated dmabuf has a singleton range 2) Teach the fault handlers to support full range semantics 3) Use dmabuf revoke variables/etc in the mmap fault handlers 4) Move the address space from the vfio to the dmabuf 5) Allow mmaping the dmabuf fd directly which is now only a couple lines I forget how all the different mmap implementations in vfio interact though - but I think the above is good for vfio-pci Jason

19 hours, 27 minutes

Is It Possible to Get Back Crypto Sent to a Scammer?

by Jasper Ryder

CRYPTO SCAM RECOVERY SERVICE 2026: BITCRACK RECOVERY EXPERTS (BRE) – THE BEST AND MOST LEGITIMATE CRYPTOCURRENCY RECOVERY COMPANY Losing cryptocurrency to scams, hacking incidents, hardware wallet failures, forgotten seed phrases, or fraudulent investment platforms can be financially and emotionally devastating. In 2026, the rise of sophisticated crypto fraud schemes—including pig butchering scams, phishing attacks, fake celebrity endorsements, DeFi rug pulls, and exchange collapses—has made professional cryptocurrency recovery services more essential than ever. BitCrack Recovery Experts (BRE) is widely recognized as the best and most legitimate cryptocurrency recovery company in 2026, with a proven record of recovering over $700 million worth of cryptocurrency for clients worldwide. If you’ve lost Bitcoin, Ethereum, USDT, or other digital assets, professional recovery may still be possible. Contact BitCrack Recovery Experts (BRE) Website: bcrexperts.com Email: bitcrackrecoveryexperts(a)bitcrack.co.site WhatsApp: +44 7562 744552 Why Cryptocurrency Recovery Services Are Critical in 2026 Cryptocurrency losses commonly occur due to: • Crypto scams and investment fraud – Pig butchering scams, fake ICOs, phishing schemes, and fraudulent trading platforms • Lost wallet access – Forgotten passwords, misplaced seed phrases, corrupted wallet files • Hardware wallet failures – Damaged or inaccessible Ledger or Trezor devices • Hacked accounts – Exchange breaches or compromised private keys • Unauthorized transactions – Funds transferred without consent to decentralized exchanges (DEXs) Because blockchain transactions are decentralized and irreversible, recovering stolen cryptocurrency requires specialized blockchain forensic expertise and fast action. The sooner recovery begins, the higher the chance of tracing and freezing stolen assets. This is where BitCrack Recovery Experts (BRE) leads the industry. Why BitCrack Recovery Experts Is the Best Crypto Recovery Company in 2026 Proven Recovery Record – Over $700 Million Recovered BitCrack Recovery Experts has successfully recovered more than $700 million in Bitcoin, Ethereum, and other cryptocurrencies, helping thousands of victims reclaim lost digital assets. Their consistent results place them among the most successful crypto recovery firms globally. Advanced Blockchain Forensics & AI Analytics BRE uses state-of-the-art blockchain tracing tools, AI-driven transaction analysis, and proprietary forensic software to: • Track stolen funds across multiple blockchain networks • Identify laundering patterns across DEX platforms • Analyze wallet connections and transaction pathways • Detect scam networks and coordinated fraud operations Their combination of advanced technology and human investigative expertise allows them to handle even complex cross-chain laundering cases. Global Legal & Exchange Coordination BitCrack Recovery Experts works with cryptocurrency exchanges, cybersecurity networks, and legal authorities worldwide to assist in freezing and recovering stolen assets. Their global partnerships strengthen recovery success rates in cross-border fraud cases. Transparent & Ethical Recovery Process Unlike fraudulent recovery agents who demand upfront payments or promise guaranteed returns, BRE operates with transparency and integrity. Each case begins with a professional evaluation, and clients receive clear communication throughout the recovery process. Strict Data Privacy & Security All recovery procedures follow strong cybersecurity standards to protect sensitive wallet data and financial information. Client confidentiality is a core priority. The BitCrack Recovery Process Step 1: Case Evaluation Clients provide transaction IDs, wallet addresses, communication screenshots, and scam details. BRE conducts a free consultation to assess recovery feasibility. Step 2: Blockchain Investigation Using advanced forensic software, BRE traces stolen funds across blockchain networks, identifying movement patterns—even when funds are converted to stablecoins or moved through decentralized exchanges. Step 3: Recovery Strategy Execution BRE may: • Coordinate with exchanges to freeze funds • Recover lost private keys or restore wallet access • Work with legal partners to pursue civil or criminal action Step 4: Post-Recovery Security Guidance Clients receive expert advice on wallet protection, two-factor authentication (2FA), and digital asset security to prevent future losses. Protection Against Fake Crypto Recovery Services The crypto recovery space unfortunately attracts scammers posing as recovery agents. BitCrack Recovery Experts helps victims avoid secondary fraud by: • Providing verifiable contact details • Offering transparent communication • Avoiding unrealistic guarantees • Maintaining ethical, documented procedures Their legitimacy and professional standards make BRE one of the most trusted names in crypto asset recovery. Emerging Crypto Recovery Trends in 2026 The cryptocurrency recovery industry continues evolving with: • AI-enhanced blockchain analysis • Stronger regulatory cooperation • Increased global exchange monitoring • Improved fraud detection technologies BitCrack Recovery Experts remains at the forefront of these advancements, maintaining its position as the best and most legitimate cryptocurrency recovery company in 2026. How to Prevent Future Cryptocurrency Losses BRE recommends: • Storing private keys offline using hardware wallets • Enabling multi-factor authentication on all accounts • Verifying trading platforms before investing • Backing up seed phrases securely offline • Staying updated on emerging scam tactics Education and prevention remain the first line of defense. Final Thoughts: Recover Your Cryptocurrency with Confidence Cryptocurrency scams and digital asset losses can feel irreversible—but with the right expertise, recovery is often possible. With over $700 million successfully recovered, advanced blockchain forensics, global partnerships, and a client-first approach, BitCrack Recovery Experts (BRE) stands as the leading crypto scam recovery service in 2026. Do not let fraud define your financial future. Take action quickly. Contact BitCrack Recovery Experts Today Website: bcrexperts.com Email: bitcrackrecoveryexperts(a)bitcrack.co.site WhatsApp: +44 7562 744552 BitCrack Recovery Experts — Restoring Access. Recovering Digital Assets. Rebuilding Financial Confidence.

19 hours, 45 minutes

How Can I Recover Cryptocurrency Lost to a Scam?

by mileyaustin497＠gmail.com

19 hours, 45 minutes

What Are the Most Trusted Names in Crypto Recovery?

by Abraham Ambrose

20 hours, 43 minutes

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig