Re: [PATCH 3/3] iio: buffer: Make IIO DMA fence release RCU-safe

[Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>]

On Wed, 15 Jul 2026 10:21:19 -0700
Lars-Peter Clausen <lars@metafoo.de> wrote:

> On 7/15/26 9:17 AM, Andy Shevchenko wrote:
> > On Wed, Jul 15, 2026 at 08:42:45AM -0700, Lars-Peter Clausen wrote:  
> >> The `dma_fence` documentation states that if a custom release
> >> implementation is provided, the `dma_fence` object must be freed in an
> >> RCU-safe way. The current `iio_dma_fence` implementation uses `kfree()`,
> >> which might result in a use-after-free.
> >>
> >> Remove the custom `release` implementation. This makes the DMA fence core
> >> fall back to `dma_fence_free()`, which calls `kfree_rcu()` on the fence.
> >> This requires that the fence be the first member of `struct iio_dma_fence`.
> >>
> >> Using the default release method for extended DMA fence structures is a
> >> common pattern.  
> > ...
> >  
> >> +	/*
> >> +	 * Must remain the first member so the default release callback can pass
> >> +	 * the fence directly to dma_fence_free().
> >> +	 */
> >>   	struct dma_fence base;  
> > TBH, I don't like this trick. container_of() is there for a reason. Even if
> > it's the first member in the structure. Can we simply switch to RCU version?
> > Would it require big changes?
> >  
> >> -static void iio_buffer_dma_fence_release(struct dma_fence *fence)
> >> -{
> >> -	struct iio_dma_fence *iio_fence =
> >> -		container_of(fence, struct iio_dma_fence, base);
> >> -
> >> -	kfree(iio_fence);  
> > So, we can't use dma_fence_free() here, because without above guarantee it will
> > get a wrong address. Maybe (maybe!) as a quick fix this is fine, but in long
> > term can we also have a refactoring patch that drops above comment at the end?  
> 
> I also think the container_of version is cleaner, but I checked all the 
> other implementations and 18 out of the 20 dma_fence implementations use 
> this same schema of just letting the default release handle it even when 
> embedding the struct, so it seems to be the consensus that this is the 
> way to go.
> 
Another option might be to enforce it creation time. There are some
examples of this pattern like fwctl_alloc_device().  That lets all callbacks
associated with DMA fences know it is safe to assume it is the first element
but you do have to ensure everyone allocates their fence as something like

struct my_fence *fence = dma_fence_alloc(struct my_fence, dma_fence_member_name_in_my_fence);

Given this is a fix I don't mind taking current form and assuming we might
revisit the safety of this in future.

With that in mind I've queued up all 3 patches in the fixes-togreg branch
(tweaked patch 1 for link tags as suggested).  These are a little subtle
though so I'd appreciate anyone else who has time taking a look.

Jonathan