Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

21 participants
3591 discussions

[PATCH 0/5] 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. Jiri Pirko (5): dma-mapping: avoid random addr value print out on error path dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory dma-buf: heaps: use designated initializer for exp_info dma-buf: heaps: allow heap to specify valid heap flags dma-buf: heaps: system: add an option to allocate explicitly decrypted memory drivers/dma-buf/dma-heap.c | 5 +- drivers/dma-buf/heaps/cma_heap.c | 7 ++- drivers/dma-buf/heaps/system_heap.c | 96 ++++++++++++++++++++++++++--- include/linux/dma-heap.h | 3 + include/linux/dma-mapping.h | 7 +++ include/trace/events/dma.h | 3 +- include/uapi/linux/dma-heap.h | 12 +++- kernel/dma/direct.h | 14 ++++- 8 files changed, 128 insertions(+), 19 deletions(-) -- 2.51.1

7 months, 2 weeks

HOW TO FIND A LEGITIMATE CRYPTO RECOVERY EXPERT; Contact iFORCE HACKER RECOVERY

by wsuttles6＠gmail.com

iForce Hacker Recovery are seasoned cryptocurrency specialists recognized for excellence in bitcoin fraud recovery. Their team has extensive knowledge of blockchain technology and the quickly changing cryptocurrency ecosystem, and they have a track record of assisting clients in recovering lost or stolen assets. They can successfully manage complex recovery cases because of their competence. There is still hope if you have been the victim of a cryptocurrency scam because iForce Hacker Recovery is ready to assist you in regaining the money that has been lost. Website: ht tps://iforcehackers. co m WhatsApp: +1 240-803-3706 Email: iforcehk @ consultant. c om

7 months, 2 weeks

Re: [PATCH] dma-fence: Fix sparse warnings due __rcu annotations

by Christian König

On 6/16/25 17:59, Tvrtko Ursulin wrote: > __rcu annotations on the return types from dma_fence_driver_name() and > dma_fence_timeline_name() cause sparse to complain because both the > constant signaled strings, and the strings return by the dma_fence_ops are > not __rcu annotated. > > For a simple fix it is easiest to cast them with __rcu added and undo the > smarts from the tracpoints side of things. There is no functional change > since the rest is left in place. Later we can consider changing the > dma_fence_ops return types too, and handle all the individual drivers > which define them. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> > Fixes: 506aa8b02a8d ("dma-fence: Add safe access helpers and document the rules") > Reported-by: kernel test robot <lkp(a)intel.com> > Closes: https://lore.kernel.org/oe-kbuild-all/202506162214.1eA69hLe-lkp@intel.com/ > Cc: Christian König <christian.koenig(a)amd.com> Sorry for the delayed reply, completed missed this one. Patch is reviewed and pushed to drm-misc-next. It eventually will be backported to stable kernels because of the fixes tag, but since this is not a functional bug I didn't added a CC:stable tag. Thanks, Christian. > --- > drivers/dma-buf/dma-fence.c | 8 ++++---- > include/trace/events/dma_fence.h | 35 +++++--------------------------- > 2 files changed, 9 insertions(+), 34 deletions(-) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index 3f78c56b58dc..da60d4e68b89 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -1109,9 +1109,9 @@ const char __rcu *dma_fence_driver_name(struct dma_fence *fence) > "RCU protection is required for safe access to returned string"); > > if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) > - return fence->ops->get_driver_name(fence); > + return (const char __rcu *)fence->ops->get_driver_name(fence); > else > - return "detached-driver"; > + return (const char __rcu *)"detached-driver"; > } > EXPORT_SYMBOL(dma_fence_driver_name); > > @@ -1141,8 +1141,8 @@ const char __rcu *dma_fence_timeline_name(struct dma_fence *fence) > "RCU protection is required for safe access to returned string"); > > if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) > - return fence->ops->get_driver_name(fence); > + return (const char __rcu *)fence->ops->get_driver_name(fence); > else > - return "signaled-timeline"; > + return (const char __rcu *)"signaled-timeline"; > } > EXPORT_SYMBOL(dma_fence_timeline_name); > diff --git a/include/trace/events/dma_fence.h b/include/trace/events/dma_fence.h > index 4814a65b68dc..3abba45c0601 100644 > --- a/include/trace/events/dma_fence.h > +++ b/include/trace/events/dma_fence.h > @@ -9,37 +9,12 @@ > > struct dma_fence; > > -DECLARE_EVENT_CLASS(dma_fence, > - > - TP_PROTO(struct dma_fence *fence), > - > - TP_ARGS(fence), > - > - TP_STRUCT__entry( > - __string(driver, dma_fence_driver_name(fence)) > - __string(timeline, dma_fence_timeline_name(fence)) > - __field(unsigned int, context) > - __field(unsigned int, seqno) > - ), > - > - TP_fast_assign( > - __assign_str(driver); > - __assign_str(timeline); > - __entry->context = fence->context; > - __entry->seqno = fence->seqno; > - ), > - > - TP_printk("driver=%s timeline=%s context=%u seqno=%u", > - __get_str(driver), __get_str(timeline), __entry->context, > - __entry->seqno) > -); > - > /* > * Safe only for call sites which are guaranteed to not race with fence > * signaling,holding the fence->lock and having checked for not signaled, or the > * signaling path itself. > */ > -DECLARE_EVENT_CLASS(dma_fence_unsignaled, > +DECLARE_EVENT_CLASS(dma_fence, > > TP_PROTO(struct dma_fence *fence), > > @@ -64,14 +39,14 @@ DECLARE_EVENT_CLASS(dma_fence_unsignaled, > __entry->seqno) > ); > > -DEFINE_EVENT(dma_fence_unsignaled, dma_fence_emit, > +DEFINE_EVENT(dma_fence, dma_fence_emit, > > TP_PROTO(struct dma_fence *fence), > > TP_ARGS(fence) > ); > > -DEFINE_EVENT(dma_fence_unsignaled, dma_fence_init, > +DEFINE_EVENT(dma_fence, dma_fence_init, > > TP_PROTO(struct dma_fence *fence), > > @@ -85,14 +60,14 @@ DEFINE_EVENT(dma_fence, dma_fence_destroy, > TP_ARGS(fence) > ); > > -DEFINE_EVENT(dma_fence_unsignaled, dma_fence_enable_signal, > +DEFINE_EVENT(dma_fence, dma_fence_enable_signal, > > TP_PROTO(struct dma_fence *fence), > > TP_ARGS(fence) > ); > > -DEFINE_EVENT(dma_fence_unsignaled, dma_fence_signaled, > +DEFINE_EVENT(dma_fence, dma_fence_signaled, > > TP_PROTO(struct dma_fence *fence), >

7 months, 2 weeks

[RFC v2 05/11] block: add infra to handle dmabuf tokens

by asml.silence＠gmail.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

7 months, 3 weeks

[RFC v2 04/11] block: introduce dma token backed bio type

by asml.silence＠gmail.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

7 months, 3 weeks

[RFC v2 02/11] iov_iter: introduce iter type for pre-registered dma

by asml.silence＠gmail.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

7 months, 3 weeks

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

7 months, 3 weeks

[PATCH v4 00/12] drm/amdgpu: use all SDMA instances for TTM clears and moves

by Pierre-Eric Pelloux-Prayer

The drm/ttm patch modifies TTM to support multiple contexts for the pipelined moves. Then amdgpu/ttm is updated to express dependencies between jobs explicitely, instead of relying on the ordering of execution guaranteed by the use of a single instance. With all of this in place, we can use multiple entities, with each having access to the available SDMA instances. This rework also gives the opportunity to merge the clear functions into a single one and to optimize a bit GART usage. Since v3 some patches have been already reviewed and merged separately: - https://lists.freedesktop.org/archives/amd-gfx/2026-January/137747.html - https://gitlab.freedesktop.org/drm/kernel/-/commit/ddf055b80a544d6f36f77be5… This version depend on them. v3: https://lists.freedesktop.org/archives/dri-devel/2025-November/537830.html Pierre-Eric Pelloux-Prayer (12): drm/amdgpu: allocate clear entities dynamically drm/amdgpu: allocate move entities dynamically drm/amdgpu: round robin through clear_entities in amdgpu_fill_buffer drm/amdgpu: use TTM_NUM_MOVE_FENCES when reserving fences drm/amdgpu: use multiple entities in amdgpu_move_blit drm/amdgpu: pass all the sdma scheds to amdgpu_mman drm/amdgpu: only use working sdma schedulers for ttm drm/amdgpu: create multiple clear/move ttm entities drm/amdgpu: give ttm entities access to all the sdma scheds drm/amdgpu: get rid of amdgpu_ttm_clear_buffer drm/amdgpu: rename amdgpu_fill_buffer as amdgpu_ttm_clear_buffer drm/amdgpu: split amdgpu_ttm_set_buffer_funcs_status in 2 funcs drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 16 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 17 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 329 ++++++++++-------- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 29 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 6 +- drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 13 +- drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 8 +- drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 8 +- drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 15 +- drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c | 12 +- drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 11 +- drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 14 +- drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c | 5 +- drivers/gpu/drm/amd/amdgpu/sdma_v7_0.c | 5 +- drivers/gpu/drm/amd/amdgpu/sdma_v7_1.c | 12 +- drivers/gpu/drm/amd/amdgpu/si_dma.c | 12 +- drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 5 +- drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 3 +- .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 6 +- .../drm/amd/display/amdgpu_dm/amdgpu_dm_wb.c | 6 +- 23 files changed, 300 insertions(+), 243 deletions(-) -- 2.43.0

7 months, 3 weeks

[PATCH] dma-buf: heaps: cma: register a dmem region for each cma heap

by Eric Chanudet

The cma dma-buf heaps let userspace allocate buffers in CMA regions without enforcing limits. Register a dmem region per cma heap and charge against it when allocating a buffer in a cma heap. For the default cma region, two heaps may be created for the same cma range: commit 854acbe75ff4 ("dma-buf: heaps: Give default CMA heap a fixed name") Introduced /dev/dma_heap/default_cma_region commit 4f5f8baf7341 ("dma-buf: heaps: cma: Create CMA heap for each CMA reserved region") Created a CMA heap for each CMA region, which might create a duplicate heap to the default one, e.g: /dev/dma_heap/default_cma_region /dev/dma_heap/reserved Removing the legacy heap would break user API. So handle the special case by using one dmem between the two heaps to account charges correctly. Signed-off-by: Eric Chanudet <echanude(a)redhat.com> --- In continuation with introducing cgroup for the system heap[1], 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. There is one caveat for the default cma range that may accessible through two different cma heaps, which is treated as a special case. [1] https://lore.kernel.org/all/20260116-dmabuf-heap-system-memcg-v3-0-ecc6b62c… --- drivers/dma-buf/heaps/cma_heap.c | 51 ++++++++++++++++++++++++++++++++++++---- 1 file changed, 46 insertions(+), 5 deletions(-) diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index 49cc45fb42dd7200c3c14384bcfdbe85323454b1..608af8ad6bce7fe0321da6d8f1b65a69f5d8d950 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -27,6 +27,7 @@ #include <linux/scatterlist.h> #include <linux/slab.h> #include <linux/vmalloc.h> +#include <linux/cgroup_dmem.h> #define DEFAULT_CMA_NAME "default_cma_region" @@ -46,7 +47,9 @@ int __init dma_heap_cma_register_heap(struct cma *cma) struct cma_heap { struct dma_heap *heap; struct cma *cma; + struct dmem_cgroup_region *cg; }; +static struct dmem_cgroup_region *default_cma_cg; struct cma_heap_buffer { struct cma_heap *heap; @@ -58,6 +61,7 @@ struct cma_heap_buffer { pgoff_t pagecount; int vmap_cnt; void *vaddr; + struct dmem_cgroup_pool_state *pool; }; struct dma_heap_attachment { @@ -276,6 +280,7 @@ static void cma_heap_dma_buf_release(struct dma_buf *dmabuf) kfree(buffer->pages); /* release memory */ cma_release(cma_heap->cma, buffer->cma_pages, buffer->pagecount); + dmem_cgroup_uncharge(buffer->pool, buffer->len); kfree(buffer); } @@ -319,9 +324,16 @@ static struct dma_buf *cma_heap_allocate(struct dma_heap *heap, if (align > CONFIG_CMA_ALIGNMENT) align = CONFIG_CMA_ALIGNMENT; + if (mem_accounting) { + ret = dmem_cgroup_try_charge(cma_heap->cg, size, + &buffer->pool, NULL); + if (ret) + goto free_buffer; + } + cma_pages = cma_alloc(cma_heap->cma, pagecount, align, false); if (!cma_pages) - goto free_buffer; + goto uncharge_cgroup; /* Clear the cma pages */ if (PageHighMem(cma_pages)) { @@ -376,6 +388,8 @@ static struct dma_buf *cma_heap_allocate(struct dma_heap *heap, kfree(buffer->pages); free_cma: cma_release(cma_heap->cma, cma_pages, pagecount); +uncharge_cgroup: + dmem_cgroup_uncharge(buffer->pool, size); free_buffer: kfree(buffer); @@ -390,25 +404,52 @@ static int __init __add_cma_heap(struct cma *cma, const char *name) { struct dma_heap_export_info exp_info; struct cma_heap *cma_heap; + struct dmem_cgroup_region *region; + int ret; cma_heap = kzalloc(sizeof(*cma_heap), GFP_KERNEL); if (!cma_heap) return -ENOMEM; cma_heap->cma = cma; + /* + * If two heaps are created for the default cma region, use the same + * dmem for them. They both use the same memory pool. + */ + if (dev_get_cma_area(NULL) == cma && default_cma_cg) + region = default_cma_cg; + else { + region = dmem_cgroup_register_region(cma_get_size(cma), "cma/%s", name); + if (IS_ERR(region)) { + ret = PTR_ERR(region); + goto free_cma_heap; + } + } + cma_heap->cg = region; + exp_info.name = name; exp_info.ops = &cma_heap_ops; exp_info.priv = cma_heap; cma_heap->heap = dma_heap_add(&exp_info); if (IS_ERR(cma_heap->heap)) { - int ret = PTR_ERR(cma_heap->heap); - - kfree(cma_heap); - return ret; + ret = PTR_ERR(cma_heap->heap); + goto cg_unregister; } + if (dev_get_cma_area(NULL) == cma && !default_cma_cg) + default_cma_cg = region; + return 0; + +cg_unregister: + /* default_cma_cg == cma_heap->cg only for the duplicate heap. */ + if (default_cma_cg != cma_heap->cg) + dmem_cgroup_unregister_region(cma_heap->cg); +free_cma_heap: + kfree(cma_heap); + + return ret; } static int __init add_cma_heaps(void) --- base-commit: 3d65e4c276b32c03450261d114e495fda03c8e97 change-id: 20260128-dmabuf-heap-cma-dmem-f4120a2df4a8 Best regards, -- Eric Chanudet <echanude(a)redhat.com>

7 months, 3 weeks

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

by Leon Romanovsky

Changelog: v6: * 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 | 84 ++++++++++++++++++++++------- include/linux/dma-buf.h | 17 +++--- 15 files changed, 157 insertions(+), 96 deletions(-) --- base-commit: 61ceaf236115f20f4fdd7cf60f883ada1063349a change-id: 20251221-dmabuf-revoke-b90ef16e4236 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

8 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig