Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

19 participants
3649 discussions

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), >

8 months, 1 week

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

8 months, 2 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.

8 months, 2 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.

8 months, 2 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>

8 months, 2 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

8 months, 2 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>

8 months, 2 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, 3 weeks

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

by Leon Romanovsky

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

8 months, 3 weeks

[RFC v2 0/8] dma-buf: Add support for mapping dmabufs via interconnects

by Vivek Kasireddy

In a typical dma-buf use case, a dmabuf exporter makes its buffer buffer available to an importer by mapping it using DMA APIs such as dma_map_sgtable() or dma_map_resource(). However, this is not desirable in some cases where the exporter and importer are directly connected via a physical or virtual link (or interconnect) and the importer can access the buffer without having it DMA mapped. So, to address this scenario, this patch series adds APIs to map/ unmap dmabufs via interconnects and also provides a helper to identify the first common interconnect between the exporter and importer. Furthermore, this patch series also adds support for IOV interconnect in the vfio-pci driver and Intel Xe driver. The IOV interconnect is a virtual interconnect between an SRIOV physical function (PF) and its virtual functions (VFs). And, for the IOV interconnect, the addresses associated with a buffer are shared using an xarray (instead of an sg_table) that is populated with entries of type struct range. The dma-buf patches in this series are based on ideas/suggestions provided by Jason Gunthorpe, Christian Koenig and Thomas Hellström. Changelog: RFC -> RFCv2: - Add documentation for the new dma-buf APIs and types (Thomas) - Change the interconnect type from enum to unique pointer (Thomas) - Moved the new dma-buf APIs to a separate file - Store a copy of the interconnect matching data in the attachment - Simplified the macros to create and match interconnects - Use struct device instead of struct pci_dev in match data - Replace DRM_INTERCONNECT_DRIVER with XE_INTERCONNECT_VRAM during address encoding (Matt, Thomas) - Drop is_devmem_external and instead rely on bo->dma_data.dma_addr to check for imported VRAM BOs (Matt) - Pass XE_PAGE_SIZE as the last parameter to xe_bo_addr (Matt) - Add a check to prevent malicious VF from accessing other VF's addresses (Thomas) - Fallback to legacy (map_dma_buf) mapping method if mapping via interconnect fails Patchset overview: Patch 1-3: Add dma-buf APIs to map/unmap and match Patch 4: Add support for IOV interconnect in vfio-pci driver Patch 5: Add support for IOV interconnect in Xe driver Patch 6-8: Create and use a new dma_addr array for LMEM based dmabuf BOs to store translated addresses (DPAs) This series is rebased on top of the following repo: https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=… Associated Qemu patch series: https://lore.kernel.org/qemu-devel/20251003234138.85820-1-vivek.kasireddy@i… Associated vfio-pci patch series: https://lore.kernel.org/dri-devel/cover.1760368250.git.leon@kernel.org/ This series is tested using the following method: - Run Qemu with the following relevant options: qemu-system-x86_64 -m 4096m .... -device ioh3420,id=root_port1,bus=pcie.0 -device x3130-upstream,id=upstream1,bus=root_port1 -device xio3130-downstream,id=downstream1,bus=upstream1,chassis=9 -device xio3130-downstream,id=downstream2,bus=upstream1,chassis=10 -device vfio-pci,host=0000:03:00.1,bus=downstream1 -device virtio-gpu,max_outputs=1,blob=true,xres=1920,yres=1080,bus=downstream2 -display gtk,gl=on -object memory-backend-memfd,id=mem1,size=4096M -machine q35,accel=kvm,memory-backend=mem1 ... - Run Gnome Wayland with the following options in the Guest VM: # cat /usr/lib/udev/rules.d/61-mutter-primary-gpu.rules ENV{DEVNAME}=="/dev/dri/card1", TAG+="mutter-device-preferred-primary", TAG+="mutter-device-disable-kms-modifiers" # XDG_SESSION_TYPE=wayland dbus-run-session -- /usr/bin/gnome-shell --wayland --no-x11 & Cc: Jason Gunthorpe <jgg(a)nvidia.com> Cc: Leon Romanovsky <leonro(a)nvidia.com> Cc: Christian Koenig <christian.koenig(a)amd.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: Simona Vetter <simona.vetter(a)ffwll.ch> Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: Dongwon Kim <dongwon.kim(a)intel.com> Vivek Kasireddy (8): dma-buf: Add support for map/unmap APIs for interconnects dma-buf: Add a helper to match interconnects between exporter/importer dma-buf: Create and expose IOV interconnect to all exporters/importers vfio/pci/dmabuf: Add support for IOV interconnect drm/xe/dma_buf: Add support for IOV interconnect drm/xe/pf: Add a helper function to get a VF's backing object in LMEM drm/xe/bo: Create new dma_addr array for dmabuf BOs associated with VFs drm/xe/pt: Add an additional check for dmabuf BOs while doing bind drivers/dma-buf/Makefile | 2 +- drivers/dma-buf/dma-buf-interconnect.c | 164 +++++++++++++++++++++ drivers/dma-buf/dma-buf.c | 12 +- drivers/gpu/drm/xe/xe_bo.c | 162 ++++++++++++++++++-- drivers/gpu/drm/xe/xe_bo_types.h | 6 + drivers/gpu/drm/xe/xe_dma_buf.c | 17 ++- drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c | 24 +++ drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h | 1 + drivers/gpu/drm/xe/xe_pt.c | 8 + drivers/gpu/drm/xe/xe_sriov_pf_types.h | 19 +++ drivers/vfio/pci/vfio_pci_dmabuf.c | 135 ++++++++++++++++- include/linux/dma-buf-interconnect.h | 122 +++++++++++++++ include/linux/dma-buf.h | 41 ++++++ 13 files changed, 691 insertions(+), 22 deletions(-) create mode 100644 drivers/dma-buf/dma-buf-interconnect.c create mode 100644 include/linux/dma-buf-interconnect.h -- 2.50.1

8 months, 3 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig