diff options
| author | Lars-Peter Clausen <lars@metafoo.de> | 2026-07-15 08:42:45 -0700 |
|---|---|---|
| committer | Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> | 2026-08-07 23:51:04 +0100 |
| commit | 8662e56c31cf23b61ca3d11b516efb94c35b8026 (patch) | |
| tree | ce273fbf1b9f3d80094b1501901d3dd39a74c066 /tools/perf/scripts/python | |
| parent | f25ec4627d935dedfb5fe83bd2c2678cdcc19611 (diff) | |
| download | linux-8662e56c31cf23b61ca3d11b516efb94c35b8026.tar.gz linux-8662e56c31cf23b61ca3d11b516efb94c35b8026.zip | |
iio: buffer: Make IIO DMA fence release RCU-safe
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.
Reported-by: codex:gpt-5.6
Fixes: 3e26d9f08fbe ("iio: core: Add new DMABUF interface infrastructure")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions
