Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

21 participants
3586 discussions

Re: [PATCH v3 06/11] mm/cma: Allow dynamically creating CMA areas

by T.J. Mercier

On Thu, Aug 6, 2026 at 9:21 AM Thierry Reding <thierry.reding(a)kernel.org> wrote: > > On Wed, Jul 08, 2026 at 04:49:31PM -0700, T.J. Mercier wrote: > > On Wed, Jul 1, 2026 at 9:09 AM Thierry Reding <thierry.reding(a)kernel.org> wrote: > > > > > > From: Thierry Reding <treding(a)nvidia.com> > > > > > > There is no technical reason why there should be a limited number of CMA > > > regions, so extract some code into helpers and use them to create extra > > > functions (cma_create() and cma_free()) that allow creating and freeing, > > > respectively, CMA regions dynamically at runtime. > > > > > > The static array of CMA areas cannot be replaced by dynamically created > > > areas because for many of them, allocation must not fail and some cases > > > may need to initialize them before the slab allocator is even available. > > > To account for this, keep these "early" areas in a separate list and > > > track the dynamic areas in a separate list. > > Huh... going over this thread again I could've sworn that I had replied > to this before, but I can't find any evidence of any reply. > > > Hi, It looks like you'll also need to update the CMA dma-buf heap's > > add_cma_heaps init function so that it adds all the CMA areas, not > > just the early ones. > > I would actually rather not do that. The case that we need this for is > creating a special purpose dma-buf heap that's composed of multiple CMA > areas. These areas must not be used by anyone else. Exposing these to > the CMA dma-buf heap would allow anyone to allocate from individual > chunks and throw off the accounting that we need to do in order to keep > the protected memory from working correctly. > > Besides, given the dynamic nature of this means that the CMA dma-buf > heap might already have probed when these dynamic CMA areas are added. > So we would either need to have some way of notifying the CMA dma-buf > heap of newly created areas or we might end up with an incomplete set > of registered heaps. > > If you really insist, I could look into this, but I think it's actually > a nice feature that the CMA dma-buf heap only registers these "early" > areas and exposes them. > > Thierry No problem, thanks for responding. I see there is now discussion about subdividing a single CMA area for this, and that seems like it could end up simpler in terms of the CMA code for this series. So I'm supportive of that idea.

1 month, 1 week

Re: [PATCH 3/5] drm/amdgpu/userq: bound the eviction fence rearm retry loop

by Christian König

On 8/10/26 18:13, Junrui Luo via B4 Relay wrote: > From: Junrui Luo <moonafterrain(a)outlook.com> > > amdgpu_userq_ensure_ev_fence() loops until the eviction fence is both > present and unsignaled. The only producer of such a fence is > amdgpu_evf_mgr_rearm(), which runs as the very last step of > amdgpu_userq_vm_validate(). Every failure point ahead of it - the > kzalloc() in the rearm itself, amdgpu_hmm_range_alloc(), the > ttm_bo_validate() calls, the GART binding of the wptr BOs - makes > amdgpu_userq_restore_worker() give up with only a drm_file_err(). > Nothing propagates that back, so the waiting thread reschedules the > worker and flushes it again, forever. > > Both flush_delayed_work() and mutex_lock() sleep in > TASK_UNINTERRUPTIBLE, so the looping task cannot be killed and the OOM > killer cannot reclaim it. An unprivileged render node client > reaches this from both AMDGPU_USERQ and AMDGPU_USERQ_SIGNAL. > > The eviction fence sequence number is already bumped by every > successful rearm, so use it as the loop's progress condition: if a > completed flush of the restore worker did not move it then no rearm > happened and retrying cannot help. Return -ENOMEM in that case and > let both callers report it to userspace. > > Fixes: a242a3e4b5be ("drm/amdgpu: simplify eviction fence suspend/resume") > Reported-by: Yuhao Jiang <danisjiang(a)gmail.com> > Assisted-by: Claude:claude-opus-5 > Cc: stable(a)vger.kernel.org > Signed-off-by: Junrui Luo <moonafterrain(a)outlook.com> Absolutely clear NAK! This functions needs to loop forever should the rearm worker fails to re-arm the fence. The only thing which could potentially get out of that is to kill the process or maybe that the eviction fence is signaled with an error. Regards, Christian. > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 21 +++++++++++++++++++-- > drivers/gpu/drm/amd/amdgpu/amdgpu_userq.h | 4 ++-- > drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c | 10 +++++++++- > 3 files changed, 30 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c > index bec107216811..208b53ae5bd1 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c > @@ -448,12 +448,16 @@ static void amdgpu_userq_cleanup(struct amdgpu_usermode_queue *queue) > * Ensures that a valid and not yet signaled eviction fence is attached to the > * usermode queue before any queue operations proceed. If it is signalled, then > * rearm a new eviction fence. > + * > + * Returns 0 with @uq_mgr->userq_mutex held, or -ENOMEM with the mutex released > + * when the restore worker could not rearm the fence. > */ > -void > +int > amdgpu_userq_ensure_ev_fence(struct amdgpu_userq_mgr *uq_mgr, > struct amdgpu_eviction_fence_mgr *evf_mgr) > { > struct dma_fence *ev_fence; > + int seq, prev_seq = -1; > > retry: > /* Flush any pending resume work to create ev_fence */ > @@ -463,7 +467,16 @@ amdgpu_userq_ensure_ev_fence(struct amdgpu_userq_mgr *uq_mgr, > ev_fence = amdgpu_evf_mgr_get_fence(evf_mgr); > if (dma_fence_is_signaled(ev_fence)) { > dma_fence_put(ev_fence); > + seq = atomic_read(&evf_mgr->ev_fence_seq); > mutex_unlock(&uq_mgr->userq_mutex); > + /* > + * The sequence number is only bumped by a successful rearm, so > + * if the flush above ran the worker without moving it then the > + * restore failed and looping again would never terminate. > + */ > + if (seq == prev_seq) > + return -ENOMEM; > + prev_seq = seq; > /* > * Looks like there was no pending resume work, > * add one now to create a valid eviction fence > @@ -472,6 +485,8 @@ amdgpu_userq_ensure_ev_fence(struct amdgpu_userq_mgr *uq_mgr, > goto retry; > } > dma_fence_put(ev_fence); > + > + return 0; > } > > > @@ -747,7 +762,9 @@ amdgpu_userq_create(struct drm_file *filp, union drm_amdgpu_userq *args) > if (r) > goto clean_mqd; > > - amdgpu_userq_ensure_ev_fence(&fpriv->userq_mgr, &fpriv->evf_mgr); > + r = amdgpu_userq_ensure_ev_fence(&fpriv->userq_mgr, &fpriv->evf_mgr); > + if (r) > + goto erase_doorbell; > > /* don't map the queue if scheduling is halted */ > if (!adev->userq_halt_for_enforce_isolation || > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.h > index 6412a7f7b6ef..c35909bf7ceb 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.h > @@ -164,8 +164,8 @@ void amdgpu_userq_mgr_fini(struct amdgpu_userq_mgr *userq_mgr); > > void amdgpu_userq_evict(struct amdgpu_userq_mgr *uq_mgr); > > -void amdgpu_userq_ensure_ev_fence(struct amdgpu_userq_mgr *userq_mgr, > - struct amdgpu_eviction_fence_mgr *evf_mgr); > +int amdgpu_userq_ensure_ev_fence(struct amdgpu_userq_mgr *userq_mgr, > + struct amdgpu_eviction_fence_mgr *evf_mgr); > > u32 amdgpu_userq_get_supported_ip_mask(struct amdgpu_device *adev); > bool amdgpu_userq_enabled(struct drm_device *dev); > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c > index 7e80442ec3e5..1c287ce59736 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c > @@ -523,7 +523,15 @@ int amdgpu_userq_signal_ioctl(struct drm_device *dev, void *data, > goto put_queue; > > /* We are here means UQ is active, make sure the eviction fence is valid */ > - amdgpu_userq_ensure_ev_fence(&fpriv->userq_mgr, &fpriv->evf_mgr); > + r = amdgpu_userq_ensure_ev_fence(&fpriv->userq_mgr, &fpriv->evf_mgr); > + if (r) { > + /* The fence is not initialized yet, so unwind it by hand */ > + amdgpu_userq_fence_put_fence_drv_array(fence); > + amdgpu_userq_fence_driver_put(fence->fence_drv); > + kvfree(fence->fence_drv_array); > + kfree(fence); > + goto put_queue; > + } > > /* Create the new fence */ > amdgpu_userq_fence_init(queue, fence, wptr); >

1 month, 1 week

Re: [PATCH v4 06/10] dma-buf: heaps: Add debugfs support

by Christian König

On 8/7/26 17:54, Thierry Reding wrote: > From: Thierry Reding <treding(a)nvidia.com> > > Add a callback to struct dma_heap_ops that heap providers can implement > to show information about the state of the heap in debugfs. A top-level > directory named "dma_heap" is created in debugfs and individual files > will be named after the heaps. > > Reviewed-by: Maxime Ripard <mripard(a)kernel.org> > Signed-off-by: Thierry Reding <treding(a)nvidia.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/dma-buf/dma-heap.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++ > include/linux/dma-heap.h | 2 ++ > 2 files changed, 58 insertions(+) > > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c > index 3937dd41bb0f..389cddd07c8d 100644 > --- a/drivers/dma-buf/dma-heap.c > +++ b/drivers/dma-buf/dma-heap.c > @@ -7,6 +7,7 @@ > */ > > #include <linux/cdev.h> > +#include <linux/debugfs.h> > #include <linux/device.h> > #include <linux/dma-buf.h> > #include <linux/dma-heap.h> > @@ -225,6 +226,46 @@ const char *dma_heap_get_name(struct dma_heap *heap) > } > EXPORT_SYMBOL_NS_GPL(dma_heap_get_name, "DMA_BUF_HEAP"); > > +#ifdef CONFIG_DEBUG_FS > +static int dma_heap_debug_show(struct seq_file *s, void *unused) > +{ > + struct dma_heap *heap = s->private; > + int err = 0; > + > + if (heap->ops && heap->ops->show) > + err = heap->ops->show(s, heap); > + > + return err; > +} > +DEFINE_SHOW_ATTRIBUTE(dma_heap_debug); > + > +static struct dentry *dma_heap_debugfs_dir; > + > +static void dma_heap_init_debugfs(void) > +{ > + struct dentry *dir; > + > + dir = debugfs_create_dir("dma_heap", NULL); > + if (IS_ERR(dir)) > + return; > + > + dma_heap_debugfs_dir = dir; > +} > + > +static void dma_heap_exit_debugfs(void) > +{ > + debugfs_remove_recursive(dma_heap_debugfs_dir); > +} > +#else > +static void dma_heap_init_debugfs(void) > +{ > +} > + > +static void dma_heap_exit_debugfs(void) > +{ > +} > +#endif > + > /** > * dma_heap_add - adds a heap to dmabuf heaps > * @exp_info: information needed to register this heap > @@ -299,6 +340,13 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info) > > /* Add heap to the list */ > list_add(&heap->list, &heap_list); > + > +#ifdef CONFIG_DEBUG_FS > + if (heap->ops && heap->ops->show) > + debugfs_create_file(heap->name, 0444, dma_heap_debugfs_dir, > + heap, &dma_heap_debug_fops); > +#endif > + > mutex_unlock(&heap_list_lock); > > return heap; > @@ -335,6 +383,14 @@ static int dma_heap_init(void) > } > dma_heap_class->devnode = dma_heap_devnode; > > + dma_heap_init_debugfs(); > + > return 0; > } > subsys_initcall(dma_heap_init); > + > +static void __exit dma_heap_exit(void) > +{ > + dma_heap_exit_debugfs(); > +} > +__exitcall(dma_heap_exit); > diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h > index 648328a64b27..1c9bed1f4dde 100644 > --- a/include/linux/dma-heap.h > +++ b/include/linux/dma-heap.h > @@ -12,6 +12,7 @@ > #include <linux/types.h> > > struct dma_heap; > +struct seq_file; > > /** > * struct dma_heap_ops - ops to operate on a given heap > @@ -24,6 +25,7 @@ struct dma_heap_ops { > unsigned long len, > u32 fd_flags, > u64 heap_flags); > + int (*show)(struct seq_file *s, struct dma_heap *heap); > }; > > /** >

1 month, 1 week

Re: [PATCH v9 0/5] rust / dma_buf: Add abstractions for dma_fence

by Miguel Ojeda

On Wed, Aug 5, 2026 at 5:01 PM Philipp Stanner <phasta(a)kernel.org> wrote: > > rust: types: implement ForeignOwnable for ARef<T> > rust: sync: Add abstraction for rcu_barrier() > rust: error: add remaining error codes Applied (these three) to `rust-next` -- thanks everyone! Please note that your Signed-off-by is required when sending a patch from someone else: https://docs.kernel.org/process/submitting-patches.html#sign-your-work-the-… I added it here on apply for you -- please let me know if that is not what you intended! [ Formatted comments. Added the submitter's Signed-off-by tag. - Miguel ] [ Relaxed `'static` bound and added `#[inline]` as discussed. Added the submitter's Signed-off-by tag. - Miguel ] [ Formatted documentation. Sorted tags. - Miguel ] Thanks! Cheers, Miguel

1 month, 2 weeks

Re: [PATCH net-next v8 0/3] net: devmem: allow rx-buf-size > PAGE_SIZE per binding

by patchwork-bot+netdevbpf＠kernel.org

Hello: This series was applied to netdev/net-next.git (main) by Jakub Kicinski <kuba(a)kernel.org>: On Wed, 05 Aug 2026 13:42:42 -0700 you wrote: > Every devmem dmabuf binding hands the page_pool PAGE_SIZE niovs today. > On NICs that consume one descriptor per netmem, this caps a single RX > descriptor at PAGE_SIZE and burns CPU on buffer churn. > > In this series, we add a bind-time netlink attribute, > NETDEV_A_DMABUF_RX_BUF_SIZE, that lets userspace request a larger niov > size (power of two >= PAGE_SIZE). Drivers must opt in via > queue_mgmt_ops.QCFG_RX_PAGE_SIZE. > > [...] Here is the summary with links: - [net-next,v8,1/3] net: devmem: allow rx-page-size > PAGE_SIZE per dmabuf binding https://git.kernel.org/netdev/net-next/c/b27a8560eec9 - [net-next,v8,2/3] selftests/net: ncdevmem: add -b option to set rx-page-size on bind https://git.kernel.org/netdev/net-next/c/3e8c9ec4eb75 - [net-next,v8,3/3] selftests/net: devmem.py: add check_rx_large_niov https://git.kernel.org/netdev/net-next/c/8ac4255c1e0c You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html

1 month, 2 weeks

Re: [PATCH v6 4/4] selftests: dmabuf-heaps: add fd-leak-on-EFAULT regression test

by T.J. Mercier

On Fri, Aug 7, 2026 at 3:12 AM Baineng Shou <shoubaineng(a)gmail.com> wrote: > > Add a test case that verifies no file descriptor is leaked when > DMA_HEAP_IOCTL_ALLOC succeeds internally but copy_to_user() fails > to deliver the fd number back to userspace. > > The failure is triggered by placing the ioctl argument in a private > anonymous page and flipping it to PROT_READ (via mprotect) between > the kernel's copy_from_user() and copy_to_user() calls. With the > buggy kernel the ioctl returns -EFAULT but leaves an extra open fd > in the process's fd table; with the fixed kernel the fd count is > unchanged. > > This serves as a regression test for: > "dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds" > > Suggested-by: Sumit Semwal <sumit.semwal(a)linaro.org> > Signed-off-by: Baineng Shou <shoubaineng(a)gmail.com> Reviewed-by: T.J. Mercier <tjmercier(a)google.com>

1 month, 2 weeks

Re: [PATCH v9 2/5] rust: types: implement ForeignOwnable for ARef<T>

by Gary Guo

On Wed Aug 5, 2026 at 3:59 PM BST, Philipp Stanner wrote: > From: Danilo Krummrich <dakr(a)kernel.org> > > Implement ForeignOwnable for ARef<T>, making it possible for C code to > own an ARef<T>. > > Since ARef represents shared ownership, BorrowedMut is &T rather than > &mut T, matching the semantics of the underlying reference-counted type. > > Signed-off-by: Danilo Krummrich <dakr(a)kernel.org> > Reviewed-by: Alice Ryhl <aliceryhl(a)google.com> > Tested-by: Daniel Almeida <daniel.almeida(a)collabora.com> > --- > rust/kernel/sync/aref.rs | 40 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 40 insertions(+) > > diff --git a/rust/kernel/sync/aref.rs b/rust/kernel/sync/aref.rs > index b721b2e00b98..540766613659 100644 > --- a/rust/kernel/sync/aref.rs > +++ b/rust/kernel/sync/aref.rs > @@ -24,6 +24,11 @@ > ptr::NonNull, // > }; > > +use crate::{ > + prelude::*, > + types::ForeignOwnable, // > +}; > + > /// Types that are _always_ reference counted. > /// > /// It allows such types to define their own custom ref increment and decrement functions. > @@ -188,6 +193,41 @@ fn eq(&self, other: &ARef<U>) -> bool { > } > impl<T: AlwaysRefCounted + Eq> Eq for ARef<T> {} > > +// SAFETY: `into_foreign` returns a pointer from `NonNull::as_ptr`, so it's non-null. The > +// `ARef` invariant guarantees that `ptr` points to a valid `T`, so it's aligned to `T`. > +unsafe impl<T: AlwaysRefCounted + 'static> ForeignOwnable for ARef<T> { > + const FOREIGN_ALIGN: usize = core::mem::align_of::<T>(); > + > + type Borrowed<'a> = &'a T; > + type BorrowedMut<'a> = &'a T; > + `#[inline]` here and all others. Best, Gary > + fn into_foreign(self) -> *mut c_void { > + ARef::into_raw(self).as_ptr().cast() > + } > + > + unsafe fn from_foreign(ptr: *mut c_void) -> Self { > + // SAFETY: The safety requirements of this function ensure that `ptr` comes from a previous > + // call to `Self::into_foreign`. > + let ptr = unsafe { NonNull::new_unchecked(ptr.cast()) }; > + > + // SAFETY: `ptr` came from `into_foreign`, which consumed an `ARef` without decrementing > + // the refcount, so we can transfer the ownership to the new `ARef`. > + unsafe { ARef::from_raw(ptr) } > + } > + > + unsafe fn borrow<'a>(ptr: *mut c_void) -> &'a T { > + // SAFETY: The safety requirements of this method ensure that the object remains alive and > + // immutable for the duration of 'a. > + unsafe { &*ptr.cast() } > + } > + > + unsafe fn borrow_mut<'a>(ptr: *mut c_void) -> &'a T { > + // SAFETY: The safety requirements for `borrow_mut` are a superset of the safety > + // requirements for `borrow`. > + unsafe { <Self as ForeignOwnable>::borrow(ptr) } > + } > +} > + > impl<T, U> PartialEq<&'_ U> for ARef<T> > where > T: AlwaysRefCounted + PartialEq<U>,

1 month, 2 weeks

Re: [PATCH v4 01/14] dma-buf: introduce initial file I/O infrastructure

by Christian König

On 8/5/26 12:59, Pavel Begunkov wrote: > On 8/5/26 09:27, Christian König wrote: >>> + >>> + dma_resv_lock(dmabuf->resv, NULL); >>> + ctx->dev_ops->unmap(ctx, map); >>> + dma_resv_unlock(dmabuf->resv); >>> + >>> + dma_fence_put(&fence->base); >> >> You should probably set map->fence to NULL after that. > > The map is freed two lines below, but I can add it as > a defensive measure. In that case it's ok, I've just haven't seen the kfree(map) below. > ... >>> + ret = dma_resv_reserve_fences(dmabuf->resv, 1); >>> + if (WARN_ON_ONCE(ret)) { >>> + struct dma_fence *fence = &map->fence->base; >>> + >>> + dma_fence_get(fence); >>> + percpu_ref_kill(&map->refs); >>> + dma_fence_wait(fence, false); >>> + dma_fence_put(fence); >>> + return; >>> + } >>> + >>> + dma_resv_add_fence(dmabuf->resv, &map->fence->base, >>> + DMA_RESV_USAGE_KERNEL); >> >> That sequence is clearly incorrect! >> >> The fence must be created after dma_resv_reserve_fences(), otherwise you definately have an illegal memory operation here. > > I'm not sure what you mean, can you elaborate? I only cared about > pre-allocating it to avoid allocations here. We add / signal the fence > only once, no reuse. The map is going to be killed here, and if we > create a new map, it'll have its own fence. > > I can move the dma_fence_init() call here if that makes a difference? Yeah that is a good start, but you might need a bit more. Here is a summary of the usual procedure you need to follow when implementing a dma_fence backend: 1. Allocate your operation object, in this case here it's your mapping I think. 2. Prepare your operation, including all memory allocations. 3. Call dma_resv_reserve_fences() to reserve a fence slot. 4. Allocate and init your dma_fence object. After this step no memory allocation is allowed any more until your dma_fence object signals. The only exception is optional logging or crash dumping using GFP_NOWAIT (can fail trivially!) or minimal allocations using GFP_ATOMIC if you absolutely have to. 5. dma_resv_add_fence() to publish the fence. 6. dma_resv_unlock(). Having a dma_fence is certainly nice to have, but the tricky part is that memory allocations using GFP_KERNEL (or GFP_IO, GFP_FS etc...) can cycle back and wait for your dma_fence to signal which essentially can cause a deadlock very deeply inside memory management. Since those deadlocks happen only on memory contention situations they are usually just hard to reproduce but still totally break your neck if you manage to mess this up. So that needs to be super carefully implemented. Regards, Christian.

1 month, 2 weeks

Re: [PATCH v4 01/14] dma-buf: introduce initial file I/O infrastructure

by Christian König

On 7/28/26 23:29, Pavel Begunkov wrote: > The goal is to be able to natively use dma-buf in the read-write / IO > path. This patch adds basic building blocks serving as a glue and API > between drivers and upper layer subsystems providing the uAPI. Later > patches implement it for NVMe raw block devices and expose it to the > user space via io_uring. > > There are two main objects. struct dma_buf_io_ctx and struct > dma_buf_io_map. The ctx is used during initial registration and serves > as an interface between the upper layer user like io_uring and to the > importer subsystem / driver. The map represents the actual dma map > established for the target device[s] with dma_buf_map_attachment() and > stored in a device specific format. The context is created via a new > file operation ->init_dma_buf_io_ctx. > > The ctx-map separation exists to support map invalidation (see > dma_buf_io_invalidate_mappings()). A ctx can create > multiple maps during its lifetime, but there can only be no more than > one (active) map attached to it. Invalidation drops the active map > if present, and the next map will only be attempted to be created > once there is a new request that wants to use the dma-buf IO ctx. > > The primary task of the dma_buf_io_map object is to count requests > using it and to wait for their completion when we want to destroy the > DMA map. Invalidation is delayed by inserting a dma fence, which is > signaled when all flight requests are completed. > > [un]mapping and any work with dma addresses is delegated to the > importer driver via an ops table stored in the ctx, see struct > dma_buf_io_ops. Only the target driver / subsystem knows about devices > it wants to use the dma-buf with, especially in case of multi-device > filesystems or stacking in the future. > > Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> > --- > drivers/dma-buf/Makefile | 2 +- > drivers/dma-buf/dma-buf-io.c | 275 +++++++++++++++++++++++++++++++++++ > include/linux/dma-buf-io.h | 91 ++++++++++++ > include/linux/fs.h | 2 + > 4 files changed, 369 insertions(+), 1 deletion(-) > create mode 100644 drivers/dma-buf/dma-buf-io.c > create mode 100644 include/linux/dma-buf-io.h > > diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile > index b25d7550bacf..523731b0f83e 100644 > --- a/drivers/dma-buf/Makefile > +++ b/drivers/dma-buf/Makefile > @@ -1,6 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0-only > obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \ > - dma-fence-unwrap.o dma-resv.o dma-buf-mapping.o > + dma-fence-unwrap.o dma-resv.o dma-buf-mapping.o dma-buf-io.o > obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o > obj-$(CONFIG_DMABUF_HEAPS) += heaps/ > obj-$(CONFIG_SYNC_FILE) += sync_file.o > diff --git a/drivers/dma-buf/dma-buf-io.c b/drivers/dma-buf/dma-buf-io.c > new file mode 100644 > index 000000000000..5f545a1bcf32 > --- /dev/null > +++ b/drivers/dma-buf/dma-buf-io.c > @@ -0,0 +1,275 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Common infrastructure for supporing dma-buf in the I/O path. > + * > + * Copyright (C) 2026 Pavel Begunkov <asml.silence(a)gmail.com> > + */ > +#include <linux/dma-buf-io.h> > +#include <linux/dma-resv.h> > + > +struct dma_buf_io_fence { > + struct dma_fence base; > + spinlock_t lock; > +}; Upstream has change to allow embedding the spinlock into the dma_fence, so this structure here is most likely not necessary any more. > + > +static const char *dma_buf_io_fence_drv_name(struct dma_fence *fence) > +{ > + /* default fence release kfree's the base pointer */ > + BUILD_BUG_ON(offsetof(struct dma_buf_io_fence, base)); > + > + return "dma-buf-io-ctx"; > +} > + > +static const char *dma_buf_io_fence_timeline_name(struct dma_fence *fence) > +{ > + return "dma-buf-io-ctx"; > +} > + > +const struct dma_fence_ops dma_buf_io_fence_ops = { > + .get_driver_name = dma_buf_io_fence_drv_name, > + .get_timeline_name = dma_buf_io_fence_timeline_name, > +}; > + > +static void dma_buf_io_ctx_destroy_work(struct work_struct *work) > +{ > + struct dma_buf_io_ctx *ctx = container_of(work, struct dma_buf_io_ctx, > + release_work); > + > + if (WARN_ON_ONCE(refcount_read(&ctx->refs))) > + return; > + > + ctx->dev_ops->release(ctx); > + dma_buf_put(ctx->dmabuf); > + kfree(ctx); > +} > + > +static void dma_buf_io_map_release_work(struct work_struct *work) > +{ > + struct dma_buf_io_map *map = container_of(work, struct dma_buf_io_map, > + release_work); > + struct dma_buf_io_fence *fence = map->fence; > + struct dma_buf_io_ctx *ctx = map->ctx; > + struct dma_buf *dmabuf = ctx->dmabuf; > + > + /* the release path must wait for fences */ > + if (WARN_ON_ONCE(refcount_read(&ctx->refs) == 0)) > + return; Stuff like that is usually illegal. And why are you using refcount directly instead of kref? > + > + /* Prevent from destoying the ctx while unmapping */ > + refcount_inc(&ctx->refs); > + > + /* > + * There are no more requests using the map, we can signal the fence. > + * It should be done before taking the resv lock as someone could be > + * waiting for the fence while holding the lock. > + */ > + dma_fence_signal(&fence->base); Signaling fences has a whole bunch of very strict rules associated with it. E.g. you can't alocate memory for example. Are you sure you actually need and want a dma_fence here? > + > + dma_resv_lock(dmabuf->resv, NULL); > + ctx->dev_ops->unmap(ctx, map); > + dma_resv_unlock(dmabuf->resv); > + > + dma_fence_put(&fence->base); You should probably set map->fence to NULL after that. > + percpu_ref_exit(&map->refs); > + kfree(map); > + > + if (refcount_dec_and_test(&ctx->refs)) { > + /* > + * Destruction needs to wait for I/O and dma fences. Defer it to > + * simplify locking. > + */ > + INIT_WORK(&ctx->release_work, dma_buf_io_ctx_destroy_work); > + queue_work(system_wq, &ctx->release_work); > + } > +} > + > +static void dma_buf_io_map_refs_release(struct percpu_ref *ref) > +{ > + struct dma_buf_io_map *map = container_of(ref, struct dma_buf_io_map, refs); > + > + /* might sleep, use a worker */ > + INIT_WORK(&map->release_work, dma_buf_io_map_release_work); > + queue_work(system_wq, &map->release_work); > +} > + > +int dma_buf_io_init_map(struct dma_buf_io_ctx *ctx, struct dma_buf_io_map *map) > +{ > + struct dma_buf_io_fence *fence = NULL; > + int ret; > + > + fence = kzalloc(sizeof(*fence), GFP_KERNEL); > + if (!fence) > + return -ENOMEM; > + > + ret = percpu_ref_init(&map->refs, dma_buf_io_map_refs_release, 0, GFP_KERNEL); > + if (ret) { > + kfree(fence); > + return ret; > + } > + > + spin_lock_init(&fence->lock); > + dma_fence_init(&fence->base, &dma_buf_io_fence_ops, &fence->lock, > + ctx->fence_ctx, atomic_inc_return(&ctx->fence_seq)); > + map->fence = fence; > + map->ctx = ctx; > + return 0; > +} > +EXPORT_SYMBOL_NS_GPL(dma_buf_io_init_map, "DMA_BUF"); > + > +struct dma_buf_io_map *dma_buf_io_create_map(struct dma_buf_io_ctx *ctx) > +{ > + struct dma_buf *dmabuf = ctx->dmabuf; > + struct dma_buf_io_map *map; > + long ret; > + > +retry: > + /* > + * ->dmabuf_map() will be calling dma_buf_map_attachment(), for which > + * we'll need to wait for fences. Do a bit nicer and try to wait > + * without the resv lock first. > + */ Clear NAK to that. Always wait while holding the resv lock if you can! It is absolutely not beneficial to do this outside of the lock and usually just hides problems instead and prevent fixing them. > + ret = dma_resv_wait_timeout(dmabuf->resv, DMA_RESV_USAGE_KERNEL, > + true, MAX_SCHEDULE_TIMEOUT); > + if (!ret) > + ret = -EAGAIN; > + if (ret < 0) > + return ERR_PTR(ret); > + > + ret = dma_resv_lock_interruptible(dmabuf->resv, NULL); > + if (ret) > + return ERR_PTR(ret); > + > + map = dma_buf_io_get_map(ctx); > + if (map) { > + ret = 0; > + goto out; > + } > + > + if (dma_resv_wait_timeout(dmabuf->resv, DMA_RESV_USAGE_KERNEL, > + true, 0) < 0) { > + dma_resv_unlock(dmabuf->resv); > + goto retry; > + } > + > + map = ctx->dev_ops->map(ctx); > + if (IS_ERR(map)) { > + ret = PTR_ERR(map); > + goto out; > + } > + > + percpu_ref_get(&map->refs); > + rcu_assign_pointer(ctx->map, map); > +out: > + dma_resv_unlock(dmabuf->resv); > + if (ret < 0) > + return ERR_PTR(ret); > + return map; > +} > + > +static void dma_buf_io_drop_map(struct dma_buf_io_ctx *ctx) > +{ > + struct dma_buf *dmabuf = ctx->dmabuf; > + struct dma_buf_io_map *map; > + int ret; > + > + dma_resv_assert_held(dmabuf->resv); > + > + map = rcu_dereference_protected(ctx->map, > + dma_resv_held(dmabuf->resv)); > + if (!map) > + return; > + rcu_assign_pointer(ctx->map, NULL); > + > + ret = dma_resv_reserve_fences(dmabuf->resv, 1); > + if (WARN_ON_ONCE(ret)) { > + struct dma_fence *fence = &map->fence->base; > + > + dma_fence_get(fence); > + percpu_ref_kill(&map->refs); > + dma_fence_wait(fence, false); > + dma_fence_put(fence); > + return; > + } > + > + dma_resv_add_fence(dmabuf->resv, &map->fence->base, > + DMA_RESV_USAGE_KERNEL); That sequence is clearly incorrect! The fence must be created after dma_resv_reserve_fences(), otherwise you definately have an illegal memory operation here. Regards, Christian. > + /* > + * Delay destruction until all inflight requests using the map arefence-> > + * gone. It'll also signal the fence then. > + */ > + percpu_ref_kill(&map->refs); > +} > + > +void dma_buf_io_invalidate_mappings(struct dma_buf_io_ctx *ctx) > +{ > + dma_buf_io_drop_map(ctx); > +} > +EXPORT_SYMBOL_NS_GPL(dma_buf_io_invalidate_mappings, "DMA_BUF"); > + > +static void dma_buf_io_ctx_release_work(struct work_struct *work) > +{ > + struct dma_buf_io_ctx *ctx = container_of(work, struct dma_buf_io_ctx, > + release_work); > + struct dma_buf *dmabuf = ctx->dmabuf; > + long ret; > + > + dma_resv_lock(dmabuf->resv, NULL); > + /* Remove the last map, there should be no new ones going forward. */ > + dma_buf_io_drop_map(ctx); > + dma_resv_unlock(dmabuf->resv); > + > + /* Wait until all maps are destroyed. */ > + ret = dma_resv_wait_timeout(dmabuf->resv, DMA_RESV_USAGE_KERNEL, > + false, MAX_SCHEDULE_TIMEOUT); > + > + if (WARN_ON_ONCE(ret <= 0)) > + return; > + if (WARN_ON_ONCE(rcu_dereference_protected(ctx->map, true))) > + return; > + > + if (refcount_dec_and_test(&ctx->refs)) > + dma_buf_io_ctx_destroy_work(&ctx->release_work); > +} > + > +void dma_buf_io_ctx_release(struct dma_buf_io_ctx *ctx) > +{ > + /* > + * Destruction needs to wait for I/O and dma fences. Defer it to > + * simplify locking. > + */ > + INIT_WORK(&ctx->release_work, dma_buf_io_ctx_release_work); > + queue_work(system_wq, &ctx->release_work); > +} > + > +int dma_buf_io_ctx_create(struct file *file, > + struct dma_buf_io_ctx *ctx, > + struct dma_buf *dmabuf, > + enum dma_data_direction dir) > +{ > + int ret; > + > + if (!file->f_op->init_dma_buf_io_ctx) > + return -EOPNOTSUPP; > + > + memset(ctx, 0, sizeof(*ctx)); > + ctx->fence_ctx = dma_fence_context_alloc(1); > + ctx->dir = dir; > + ctx->dmabuf = dmabuf; > + refcount_set(&ctx->refs, 1); > + get_dma_buf(dmabuf); > + > + ret = file->f_op->init_dma_buf_io_ctx(file, ctx); > + if (ret) { > + memset(ctx, 0, sizeof(*ctx)); > + dma_buf_put(dmabuf); > + return ret; > + } > + > + if (WARN_ON_ONCE(!ctx->dev_ops || > + !ctx->dev_ops->map || > + !ctx->dev_ops->unmap || > + !ctx->dev_ops->release)) > + return -EINVAL; > + > + return ret; > +} > diff --git a/include/linux/dma-buf-io.h b/include/linux/dma-buf-io.h > new file mode 100644 > index 000000000000..bcffc6202556 > --- /dev/null > +++ b/include/linux/dma-buf-io.h > @@ -0,0 +1,91 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef __DMA_BUF_IO_H__ > +#define __DMA_BUF_IO_H__ > + > +#include <linux/dma-buf.h> > + > +struct dma_buf_io_fence; > +struct dma_buf_io_ctx; > +struct dma_buf_io_map; > + > +struct dma_buf_io_ops { > + /* > + * Create a new map for the given ctx. Called with the reservation > + * lock held. > + */ > + struct dma_buf_io_map *(*map)(struct dma_buf_io_ctx *ctx); > + > + /* > + * Clean up device specific parts of the @map. Called with the > + * reservation lock held. > + */ > + void (*unmap)(struct dma_buf_io_ctx *ctx, struct dma_buf_io_map *map); > + > + /* > + * The user tries to destroy the ctx. Release all device specific > + * parts of the token. > + */ > + void (*release)(struct dma_buf_io_ctx *); > +}; > + > +struct dma_buf_io_map { > + /* > + * Counts attached requests and other users. Device specific unmapping > + * is deferred until all refs are dropped. > + */ > + struct percpu_ref refs; > + > + struct work_struct release_work; > + struct dma_buf_io_fence *fence; > + struct dma_buf_io_ctx *ctx; > +}; > + > +struct dma_buf_io_ctx { > + struct dma_buf_io_map __rcu *map; > + struct dma_buf *dmabuf; > + enum dma_data_direction dir; > + > + atomic_t fence_seq; > + u64 fence_ctx; > + struct work_struct release_work; > + refcount_t refs; > + > + void *dev_priv; > + const struct dma_buf_io_ops *dev_ops; > +}; > + > +int dma_buf_io_ctx_create(struct file *file, > + struct dma_buf_io_ctx *ctx, > + struct dma_buf *dmabuf, > + enum dma_data_direction dir); > +void dma_buf_io_ctx_release(struct dma_buf_io_ctx *ctx); > + > +struct dma_buf_io_map *dma_buf_io_create_map(struct dma_buf_io_ctx *ctx); > + > +static inline struct dma_buf_io_map * > +dma_buf_io_get_map(struct dma_buf_io_ctx *ctx) > +{ > + struct dma_buf_io_map *map; > + > + guard(rcu)(); > + > + map = rcu_dereference(ctx->map); > + if (unlikely(!map || !percpu_ref_tryget_live_rcu(&map->refs))) > + return NULL; > + > + return map; > +} > + > +static inline void dma_buf_io_map_drop(struct dma_buf_io_map *map) > +{ > + percpu_ref_put(&map->refs); > +} > + > +/* > + * Device API > + */ > + > +void dma_buf_io_invalidate_mappings(struct dma_buf_io_ctx *ctx); > +int dma_buf_io_init_map(struct dma_buf_io_ctx *ctx, struct dma_buf_io_map *map); > + > +#endif > diff --git a/include/linux/fs.h b/include/linux/fs.h > index d10897b3a1e3..9fe349a279c7 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -1914,6 +1914,7 @@ struct dir_context { > #define COPY_FILE_SPLICE (1 << 0) > > struct io_uring_cmd; > +struct dma_buf_io_ctx; > struct offset_ctx; > > typedef unsigned int __bitwise fop_flags_t; > @@ -1962,6 +1963,7 @@ struct file_operations { > int (*uring_cmd_iopoll)(struct io_uring_cmd *, struct io_comp_batch *, > unsigned int poll_flags); > int (*mmap_prepare)(struct vm_area_desc *); > + int (*init_dma_buf_io_ctx)(struct file *, struct dma_buf_io_ctx *); > } __randomize_layout; > > /* Supports async buffered reads */

1 month, 2 weeks

Re: [PATCH v9 3/5] rust: sync: Add abstraction for rcu_barrier()

by Gary Guo

On Wed Aug 5, 2026 at 3:59 PM BST, Philipp Stanner wrote: > rcu_barrier() is a frequently used C function which is always safe to be > called. > > Add a safe abstraction for rcu_barrier(). > > Signed-off-by: Philipp Stanner <phasta(a)kernel.org> > Tested-by: Daniel Almeida <daniel.almeida(a)collabora.com> Acked-by: Gary Guo <gary(a)garyguo.net> > --- > rust/kernel/sync/rcu.rs | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/rust/kernel/sync/rcu.rs b/rust/kernel/sync/rcu.rs > index a32bef6e490b..7031ca5d2473 100644 > --- a/rust/kernel/sync/rcu.rs > +++ b/rust/kernel/sync/rcu.rs > @@ -50,3 +50,23 @@ fn drop(&mut self) { > pub fn read_lock() -> Guard { > Guard::new() > } > + > +/// Wait until all in-flight call_rcu() callbacks complete. This misses some `` quoting but these can be applied on fixup. Best, Gary > +/// > +/// Note that this primitive does not necessarily wait for an RCU grace period > +/// to complete. For example, if there are no RCU callbacks queued anywhere > +/// in the system, then rcu_barrier() is within its rights to return > +/// immediately, without waiting for anything, much less an RCU grace period. > +/// In fact, rcu_barrier() will normally not result in any RCU grace periods > +/// beyond those that were already destined to be executed. > +/// > +/// In kernels built with CONFIG_RCU_LAZY=y, this function also hurries all > +/// pending lazy RCU callbacks. > +/// > +/// Note that this is one of the RCU primitives which must not be called in > +/// atomic context. > +#[inline] > +pub fn rcu_barrier() { > + // SAFETY: `rcu_barrier()` is always safe to be called. It just might wait for a grace period. > + unsafe { bindings::rcu_barrier() }; > +}

1 month, 2 weeks

← Newer
1
...
8
9
10
11
12
13
14
...
359
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig