Linaro-mm-sig February 2026

linaro-mm-sig@lists.linaro.org

78 participants
1830 discussions

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!

3 days, 22 hours

5
4
10 0

[PATCH v7 0/8] dma-buf: Use revoke mechanism to invalidate shared buffers

by Leon Romanovsky

Changelog: v7: * Fixed messed VFIO patch due to rebase. v6: https://patch.msgid.link/20260130-dmabuf-revoke-v6-0-06278f9b7bf0@nvidia.com * Added Reviewed-by tags. * Changed for blocking wait_for_completion() in VFIO * Fixed race between ->attach and move_notify, where priv->revoked is flipped and lock is released. v5: https://patch.msgid.link/20260124-dmabuf-revoke-v5-0-f98fca917e96@nvidia.com * Documented the DMA-BUF expectations around DMA unmap. * Added wait support in VFIO for DMA unmap. * Reordered patches. * Improved commit messages to document even more. v4: https://lore.kernel.org/all/20260121-dmabuf-revoke-v4-0-d311cbc8633d@nvidia… * Changed DMA_RESV_USAGE_KERNEL to DMA_RESV_USAGE_BOOKKEEP. * Made .invalidate_mapping() truly optional. * Added patch which renames dma_buf_move_notify() to be dma_buf_invalidate_mappings(). * Restored dma_buf_attachment_is_dynamic() function. v3: https://lore.kernel.org/all/20260120-dmabuf-revoke-v3-0-b7e0b07b8214@nvidia… * Used Jason's wordings for commits and cover letter. * Removed IOMMUFD patch. * Renamed dma_buf_attachment_is_revoke() to be dma_buf_attach_revocable(). * Added patch to remove CONFIG_DMABUF_MOVE_NOTIFY. * Added Reviewed-by tags. * Called to dma_resv_wait_timeout() after dma_buf_move_notify() in VFIO. * Added dma_buf_attach_revocable() check to VFIO DMABUF attach function. * Slightly changed commit messages. v2: https://patch.msgid.link/20260118-dmabuf-revoke-v2-0-a03bb27c0875@nvidia.com * Changed series to document the revoke semantics instead of implementing it. v1: https://patch.msgid.link/20260111-dmabuf-revoke-v1-0-fb4bcc8c259b@nvidia.com ------------------------------------------------------------------------- This series is based on latest VFIO fix, which will be sent to Linus very soon. https://lore.kernel.org/all/20260121-vfio-add-pin-v1-1-4e04916b17f1@nvidia.… Thanks ------------------------------------------------------------------------- This series documents a dma-buf “revoke” mechanism: to allow a dma-buf exporter to explicitly invalidate (“kill”) a shared buffer after it has been distributed to importers, so that further CPU and device access is prevented and importers reliably observe failure. The change in this series is to properly document and use existing core “revoked” state on the dma-buf object and a corresponding exporter-triggered revoke operation. dma-buf has quietly allowed calling move_notify on pinned dma-bufs, even though legacy importers using dma_buf_attach() would simply ignore these calls. The intention was that move_notify() would tell the importer to expedite it's unmapping process and once the importer is fully finished with DMA it would unmap the dma-buf which finally signals that the importer is no longer ever going to touch the memory again. Importers that touch past their unmap() call can trigger IOMMU errors, AER and beyond, however read-and-discard access between move_notify() and unmap is allowed. Thus, we can define the exporter's revoke sequence for pinned dma-buf as: dma_resv_lock(dmabuf->resv, NULL); // Prevent new mappings from being established priv->revoked = true; // Tell all importers to eventually unmap dma_buf_invalidate_mappings(dmabuf); // Wait for any inprogress fences on the old mapping dma_resv_wait_timeout(dmabuf->resv, DMA_RESV_USAGE_BOOKKEEP, false, MAX_SCHEDULE_TIMEOUT); dma_resv_unlock(dmabuf->resv, NULL); // Wait for all importers to complete unmap wait_for_completion(&priv->unmapp_comp); However, dma-buf also supports importers that don't do anything on move_notify(), and will not unmap the buffer in bounded time. Since such importers would cause the above sequence to hang, a new mechanism is needed to detect incompatible importers. Introduce dma_buf_attach_revocable() which if true indicates the above sequence is safe to use and will complete in kernel-only bounded time for this attachment. Unfortunately dma_buf_attach_revocable() is going to fail for the popular RDMA pinned importer, which means we cannot introduce it to existing places using pinned move_notify() without potentially breaking existing userspace flows. Existing exporters that only trigger this flow for RAS errors should not call dma_buf_attach_revocable() and will suffer an unbounded block on the final completion, hoping that the userspace will notice the RAS and clean things up. Without revoke support on the RDMA pinned importers it doesn't seem like any other non-breaking option is currently possible. For new exporters, like VFIO and RDMA, that have userspace triggered revoke events, the unbouned sleep would not be acceptable. They can call dma_buf_attach_revocable() and will not work with the RDMA pinned importer from day 0, preventing regressions. In the process add documentation explaining the above details. Thanks Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> --- Leon Romanovsky (8): dma-buf: Rename .move_notify() callback to a clearer identifier dma-buf: Rename dma_buf_move_notify() to dma_buf_invalidate_mappings() dma-buf: Always build with DMABUF_MOVE_NOTIFY vfio: Wait for dma-buf invalidation to complete dma-buf: Make .invalidate_mapping() truly optional dma-buf: Add dma_buf_attach_revocable() vfio: Permit VFIO to work with pinned importers iommufd: Add dma_buf_pin() drivers/dma-buf/Kconfig | 12 ----- drivers/dma-buf/dma-buf.c | 69 ++++++++++++++++++++----- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 14 ++--- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +- drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +- drivers/gpu/drm/xe/tests/xe_dma_buf.c | 7 ++- drivers/gpu/drm/xe/xe_bo.c | 2 +- drivers/gpu/drm/xe/xe_dma_buf.c | 14 ++--- drivers/infiniband/core/umem_dmabuf.c | 13 ----- drivers/infiniband/hw/mlx5/mr.c | 2 +- drivers/iommu/iommufd/pages.c | 11 +++- drivers/iommu/iommufd/selftest.c | 2 +- drivers/vfio/pci/vfio_pci_dmabuf.c | 80 ++++++++++++++++++++++------- include/linux/dma-buf.h | 17 +++--- 15 files changed, 153 insertions(+), 96 deletions(-) --- base-commit: 61ceaf236115f20f4fdd7cf60f883ada1063349a change-id: 20251221-dmabuf-revoke-b90ef16e4236 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

1 week, 4 days

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

2 weeks, 3 days

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

2 weeks, 3 days

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

2 weeks, 4 days

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

by Christian König

On 2/24/26 10:43, Maxime Ripard wrote: > Hi Christian, > > On Fri, Feb 20, 2026 at 10:45:08AM +0100, Christian König wrote: >> On 2/20/26 02:14, T.J. Mercier wrote: >>> On Wed, Feb 18, 2026 at 9:15 AM Eric Chanudet <echanude(a)redhat.com> wrote: >>> >>> Hi Eric, >>> >>>> 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. >>> >>> But CMA memory is system memory, and regular (non-CMA) movable >>> allocations can occur out of these CMA areas. So this splits system >>> memory accounting between memcg (from [2]) and dmem. If I want to put >>> a limit on system memory use I have to adjust multiple limits (memcg + >>> dmems) and know how to divide the total between them all. >>> >>> How do you envision using this combination of different controllers? >> >> Yeah we have this problem pretty much everywhere. >> >> There are both use cases where you want to account device allocations >> to memcg and when you don't want that. >> >> From what I know at the moment it would be best if the administrator >> could say for each dmem if it should account additionally to memcg or >> not. >> >> Using module parameters to enable/disable it globally is just a >> workaround as far as I can see. > > That's a pretty good idea! It would indeed be a solution that could > satisfy everyone (I assume?). I think so yeah. From what I have seen we have three different use cases: 1. local device memory (VRAM), GTT/CMA and memcg are completely separate domains and you want to have completely separate values as limit for them. 2. local device memory (VRAM) is separate. GTT/CMA are accounted to memcg, you can still have separate values as limit so that nobody over allocates CMA (for example). 3. All three are accounted to memcg because system memory is actually used as fallback if applications over allocate device local memory. It's debatable what should be the default, but we clearly need to handle all three use cases. Potentially even on the same system. Regards, Christian. > > Maxime

2 weeks, 4 days

[PATCH RFC 00/26] Add DMA-buf mapping types and convert vfio/iommufd to use them

by Jason Gunthorpe

Since its introduction, DMA-buf has only supported using scatterlist for the exporter and importer to exchange address information. This is not sufficient for all use cases as dma_addr_t is a very specific and limited type that should not be abused for things unrelated to the DMA API. There are several motivations for addressing this now: 1) VFIO to IOMMUFD and KVM requires a physical address, not a dma_addr_t scatterlist, it cannot be represented in the scatterlist structure 2) xe vGPU requires the host driver to accept a DMABUF from VFIO of its own VF and convert it into an internal VRAM address on the PF 3) We are starting to look at replacement datastructures for scatterlist 4) Ideas around UALink/etc are suggesting not using the DMA API None of these can sanely be achieved using scatterlist. Introduce a new mechanism called "mapping types" which allows DMA-buf to work with more map/unmap options than scatterlist. Each mapping type encompasses a full set of functions and data unique to itself. The core code provides a match-making system to select the best type offered by the exporter and importer to be the active mapping type for the attachment. Everything related to scatterlist is moved into a DMA-buf SGT mapping type, and into the "dma_buf_sgt_*" namespace for clarity. Existing exporters are moved over to explicitly declare SGT mapping types and importers are adjusted to use the dma_buf_sgt_* named importer helpers. Mapping types are designed to be extendable, a driver can declare its own mapping type for its internal private interconnect and use that without having to adjust the core code. The new attachment sequence starts with the importing driver declaring what mapping types it can accept: struct dma_buf_mapping_match imp_match[] = { DMA_BUF_IMAPPING_MY_DRIVER(dev, ...), DMA_BUF_IMAPPING_SGT(dev, false), }; attach = dma_buf_mapping_attach(dmabuf, imp_match, ...) Most drivers will do this via a dma_buf_sgt_*attach() helper. The exporting driver can then declare what mapping types it can supply: int exporter_match_mapping(struct dma_buf_match_args *args) { struct dma_buf_mapping_match exp_match[] = { DMA_BUF_EMAPPING_MY_DRIVER(my_ops, dev, ...), DMA_BUF_EMAPPING_SGT(sgt_ops, dev, false), DMA_BUF_EMAPPING_PAL(PAL_ops), }; return dma_buf_match_mapping(args, exp_match, ...); } Most drivers will do this via a helper: static const struct dma_buf_ops ops = { DMA_BUF_SIMPLE_SGT_EXP_MATCH(map_func, unmap_func) }; During dma_buf_mapping_attach() the core code will select a mutual match between the importer and exporter and record it as the active match in the attach->map_type. Each mapping type has its own types/function calls for mapping/unmapping, and storage in the attach->map_type for its information. As such each mapping type can offer function signatures and data that exactly matches its needs. This series goes through a sequence of: 1) Introduce the basic mapping type framework and the main components of the SGT mapping type 2) Automatically make all existing exporters and importers use core generated SGT mapping types so every attachment has a SGT mapping type 3) Convert all exporter drivers to natively create a SGT mapping type 4) Move all dma_buf_* functions and types that are related to SGT into dma_buf_sgt_* 5) Remove all the now-unused items that have been moved into SGT specific structures. 6) Demonstrate adding a new Physical Address List alongside SGT. Due to the high number of files touched I would expect this to be broken into phases, but this shows the entire picture. This is on github: https://github.com/jgunthorpe/linux/commits/dmabuf_map_type It is a followup to the discussion here: https://lore.kernel.org/dri-devel/20251027044712.1676175-1-vivek.kasireddy@… Jason Gunthorpe (26): dma-buf: Introduce DMA-buf mapping types dma-buf: Add the SGT DMA mapping type dma-buf: Add dma_buf_mapping_attach() dma-buf: Route SGT related actions through attach->map_type dma-buf: Allow single exporter drivers to avoid the match_mapping function drm: Check the SGT ops for drm_gem_map_dma_buf() dma-buf: Convert all the simple exporters to use SGT mapping type drm/vmwgfx: Use match_mapping instead of dummy calls accel/habanalabs: Use the SGT mapping type drm/xe/dma-buf: Use the SGT mapping type drm/amdgpu: Use the SGT mapping type vfio/pci: Change the DMA-buf exporter to use mapping_type dma-buf: Update dma_buf_phys_vec_to_sgt() to use the SGT mapping type iio: buffer: convert to use the SGT mapping type functionfs: convert to use the SGT mapping type dma-buf: Remove unused SGT stuff from the common structures treewide: Rename dma_buf_map_attachment(_unlocked) to dma_buf_sgt_ treewide: Rename dma_buf_unmap_attachment(_unlocked) to dma_buf_sgt_* treewide: Rename dma_buf_attach() to dma_buf_sgt_attach() treewide: Rename dma_buf_dynamic_attach() to dma_buf_sgt_dynamic_attach() dma-buf: Add the Physical Address List DMA mapping type vfio/pci: Add physical address list support to DMABUF iommufd: Use the PAL mapping type instead of a vfio function iommufd: Support DMA-bufs with multiple physical ranges iommufd/selftest: Check multi-phys DMA-buf scenarios dma-buf: Add kunit tests for mapping type Documentation/gpu/todo.rst | 2 +- drivers/accel/amdxdna/amdxdna_gem.c | 14 +- drivers/accel/amdxdna/amdxdna_ubuf.c | 10 +- drivers/accel/habanalabs/common/memory.c | 54 ++- drivers/accel/ivpu/ivpu_gem.c | 10 +- drivers/accel/ivpu/ivpu_gem_userptr.c | 11 +- drivers/accel/qaic/qaic_data.c | 8 +- drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-buf-mapping.c | 186 ++++++++- drivers/dma-buf/dma-buf.c | 180 ++++++--- drivers/dma-buf/heaps/cma_heap.c | 12 +- drivers/dma-buf/heaps/system_heap.c | 13 +- drivers/dma-buf/st-dma-mapping.c | 373 ++++++++++++++++++ drivers/dma-buf/udmabuf.c | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 98 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +- drivers/gpu/drm/armada/armada_gem.c | 33 +- drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +- drivers/gpu/drm/drm_prime.c | 31 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 18 +- drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 +- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 8 +- .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 8 +- drivers/gpu/drm/msm/msm_gem_prime.c | 7 +- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 11 +- drivers/gpu/drm/tegra/gem.c | 33 +- drivers/gpu/drm/virtio/virtgpu_prime.c | 23 +- drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 32 +- drivers/gpu/drm/xe/xe_bo.c | 18 +- drivers/gpu/drm/xe/xe_dma_buf.c | 61 +-- drivers/iio/industrialio-buffer.c | 15 +- drivers/infiniband/core/umem_dmabuf.c | 15 +- drivers/iommu/iommufd/io_pagetable.h | 4 +- drivers/iommu/iommufd/iommufd_private.h | 8 - drivers/iommu/iommufd/iommufd_test.h | 7 + drivers/iommu/iommufd/pages.c | 85 ++-- drivers/iommu/iommufd/selftest.c | 177 ++++++--- .../media/common/videobuf2/videobuf2-core.c | 2 +- .../common/videobuf2/videobuf2-dma-contig.c | 26 +- .../media/common/videobuf2/videobuf2-dma-sg.c | 21 +- .../common/videobuf2/videobuf2-vmalloc.c | 13 +- .../platform/nvidia/tegra-vde/dmabuf-cache.c | 9 +- drivers/misc/fastrpc.c | 21 +- drivers/tee/tee_heap.c | 13 +- drivers/usb/gadget/function/f_fs.c | 11 +- drivers/vfio/pci/vfio_pci_dmabuf.c | 79 ++-- drivers/xen/gntdev-dmabuf.c | 29 +- include/linux/dma-buf-mapping.h | 297 ++++++++++++++ include/linux/dma-buf.h | 168 ++++---- io_uring/zcrx.c | 9 +- net/core/devmem.c | 14 +- samples/vfio-mdev/mbochs.c | 10 +- sound/soc/fsl/fsl_asrc_m2m.c | 12 +- tools/testing/selftests/iommu/iommufd.c | 43 ++ tools/testing/selftests/iommu/iommufd_utils.h | 17 + 55 files changed, 1764 insertions(+), 614 deletions(-) create mode 100644 drivers/dma-buf/st-dma-mapping.c base-commit: c63e5a50e1dd291cd95b04291b028fdcaba4c534 -- 2.43.0

2 weeks, 4 days

10 Most Credible Cryptocurrency Recovery Agency - Best Crypto Recovery Specialist

by Jane Pamela

Legitimate crypto recovery services as of 2026 Autopsy Mainnet Recovery was verified as the best cryptocurrency recovery firm Autopsy Mainnet Recovery has earned a reputation as a legitimate and reliable player in the cryptocurrency recovery space Verified as a trustworthy company in 2026 Autopsy Mainnet Recovery has successfully assisted clients in recovering lost or stolen funds from crypto scams wallet hacks and unauthorized transactions. With a team of experienced professionals, they offer tailored solutions using advanced tools and methods to trace and retrieve assets across various blockchains Email info(a)autopsymainnetsolutions.com Customers appreciate Autopsy Mainnet Recovery for its transparent processes, fast response times, and dedicated support throughout the recovery journey. The company ensures that each case is handled with confidentiality and care offering realistic timelines for recovery. Many users have praised Autopsy Mainnet Recovery for its effectiveness in restoring lost crypto making them a top choice for individuals and businesses facing cryptocurrency related losses Overall Autopsy Mainnet Recovery stands out for its professionalism success rate and commitment to helping crypto investors protect their assets Autopsy Mainnet Recovery is the world’s most legitimate and trusted crypto recovery firm delivering lawful ethical and verified solutions to recover stolen crypto USDT and hacked wallets with a proven 99 Percent success rate

2 weeks, 5 days

9 Most Credible Cryptocurrency Recovery Agency - Best Crypto Recovery Specialist

by angelaasher62＠gmail.com

2 weeks, 5 days

8 Most Credible Cryptocurrency Recovery Agency - Best Crypto Recovery Specialist

by Theodore Henry

2 weeks, 5 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig February 2026