Linaro-mm-sig January 2026

linaro-mm-sig@lists.linaro.org

44 participants
35 discussions

[PATCH 0/4] dma-buf: add revoke mechanism to invalidate shared buffers

by Leon Romanovsky

This series implements 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. Today, dma-buf effectively provides “if you have the fd, you can keep using the memory indefinitely.” That assumption breaks down when an exporter must reclaim, reset, evict, or otherwise retire backing memory after it has been shared. Concrete cases include GPU reset and recovery where old allocations become unsafe to access, memory eviction/overcommit where backing storage must be withdrawn, and security or isolation situations where continued access must be prevented. While drivers can sometimes approximate this with exporter-specific fencing and policy, there is no core dma-buf state transition that communicates “this buffer is no longer valid; fail access” across all access paths. The change in this series is to introduce a core “revoked” state on the dma-buf object and a corresponding exporter-triggered revoke operation. Once a dma-buf is revoked, new access paths are blocked so that attempts to DMA-map, vmap, or mmap the buffer fail in a consistent way. In addition, the series aims to invalidate existing access as much as the kernel allows: device mappings are torn down where possible so devices and IOMMUs cannot continue DMA. The semantics are intentionally simple: revoke is a one-way, permanent transition for the lifetime of that dma-buf instance. From a compatibility perspective, users that never invoke revoke are unaffected, and exporters that adopt it gain a core-supported enforcement mechanism rather than relying on ad hoc driver behavior. The intent is to keep the interface minimal and avoid imposing policy; the series provides the mechanism to terminate access, with policy remaining in the exporter and higher-level components. BTW, see this megathread [1] for additional context. Ironically, it was posted exactly one year ago. [1] https://lore.kernel.org/all/20250107142719.179636-2-yilun.xu@linux.intel.co… Thanks Cc: linux-rdma(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: kvm(a)vger.kernel.org Cc: iommu(a)lists.linux.dev To: Jason Gunthorpe <jgg(a)ziepe.ca> To: Leon Romanovsky <leon(a)kernel.org> To: Sumit Semwal <sumit.semwal(a)linaro.org> To: Christian König <christian.koenig(a)amd.com> To: Alex Williamson <alex(a)shazbot.org> To: Kevin Tian <kevin.tian(a)intel.com> To: Joerg Roedel <joro(a)8bytes.org> To: Will Deacon <will(a)kernel.org> To: Robin Murphy <robin.murphy(a)arm.com> Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> --- Leon Romanovsky (4): dma-buf: Introduce revoke semantics vfio: Use dma-buf revoke semantics iommufd: Require DMABUF revoke semantics iommufd/selftest: Reuse dma-buf revoke semantics drivers/dma-buf/dma-buf.c | 36 ++++++++++++++++++++++++++++++++---- drivers/iommu/iommufd/pages.c | 2 +- drivers/iommu/iommufd/selftest.c | 12 ++++-------- drivers/vfio/pci/vfio_pci_dmabuf.c | 27 ++++++--------------------- include/linux/dma-buf.h | 31 +++++++++++++++++++++++++++++++ 5 files changed, 74 insertions(+), 34 deletions(-) --- base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb change-id: 20251221-dmabuf-revoke-b90ef16e4236 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

3 months, 1 week

[RFC v2 01/11] file: add callback for pre-mapping dmabuf

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.

3 months, 1 week

[PATCH] dma-buf: system_heap: account for system heap allocation in memcg

by Eric Chanudet

The system dma-buf heap lets userspace allocate buffers from the page allocator. However, these allocations are not accounted for in memcg, allowing processes to escape limits that may be configured. Pass the __GFP_ACCOUNT for our allocations to account them into memcg. Userspace components using the system heap can be constrained with, e.g: systemd-run --user --scope -p MemoryMax=10M ... Signed-off-by: Eric Chanudet <echanude(a)redhat.com> --- drivers/dma-buf/heaps/system_heap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c index 4c782fe33fd4..c91fcdff4b77 100644 --- a/drivers/dma-buf/heaps/system_heap.c +++ b/drivers/dma-buf/heaps/system_heap.c @@ -38,10 +38,10 @@ struct dma_heap_attachment { bool mapped; }; -#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO) +#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO | __GFP_ACCOUNT) #define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \ | __GFP_NORETRY) & ~__GFP_RECLAIM) \ - | __GFP_COMP) + | __GFP_COMP | __GFP_ACCOUNT) static gfp_t order_flags[] = {HIGH_ORDER_GFP, HIGH_ORDER_GFP, LOW_ORDER_GFP}; /* * The selection of the orders used for allocation (1MB, 64K, 4K) is designed -- 2.52.0

3 months, 1 week

[RFC v2 10/11] io_uring/rsrc: add dmabuf-backed buffer registeration

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.

3 months, 1 week

[PATCH v2 00/12] media: stm32: dcmi: stability & performance enhancements

by Alain Volmat

This series improve stability of the capture by fixing the handling of the overrun which was leading to captured frame corruption. Locking within the driver is also simplified and the way DMA is handled is reworked allowing to avoid having a specific handling for the JPEG data. Performances of capture can now be increased via the usage of a DMA->MDMA chaining which allows for capture of higher resolution / framerate. Signed-off-by: Alain Volmat <alain.volmat(a)foss.st.com> --- Changes in v2: - Fix pm_sleep_ptr -> pm_ptr to avoid unused function warning - Fix typo / remove useless comment in binding - Link to v1: https://lore.kernel.org/r/20251218-stm32-dcmi-dma-chaining-v1-0-39948ca6cbf… --- Alain Volmat (12): media: stm32: dcmi: Switch from __maybe_unused to pm_ptr() media: stm32: dcmi: perform dmaengine_slave_config at probe media: stm32: dcmi: only create dma descriptor once at buf_prepare media: stm32: dcmi: stop the dma transfer on overrun media: stm32: dcmi: rework spin_lock calls media: stm32: dcmi: perform all dma handling within irq_thread media: stm32: dcmi: use dmaengine_terminate_async in irq context media: stm32: dcmi: continuous mode capture in JPEG dt-bindings: media: st: dcmi: add DMA-MDMA chaining properties media: stm32: dcmi: addition of DMA-MDMA chaining support ARM: dts: stm32: add sram node within stm32mp151.dtsi ARM: dts: stm32: enable DCMI DMA-MDMA chaining on stm32mp157c-ev1.dts .../devicetree/bindings/media/st,stm32-dcmi.yaml | 11 +- arch/arm/boot/dts/st/stm32mp151.dtsi | 8 + arch/arm/boot/dts/st/stm32mp157c-ev1.dts | 15 + drivers/media/platform/st/stm32/stm32-dcmi.c | 475 +++++++++++++-------- 4 files changed, 341 insertions(+), 168 deletions(-) --- base-commit: f7231cff1f3ff8259bef02dc4999bc132abf29cf change-id: 20251213-stm32-dcmi-dma-chaining-9ea1da83007d Best regards, -- Alain Volmat <alain.volmat(a)foss.st.com>

3 months, 2 weeks

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig January 2026