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

[Andy Shevchenko <andriy.shevchenko@intel.com>]

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?

> -}

-- 
With Best Regards,
Andy Shevchenko