]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
iio: buffer: Fix DMA fence leak in iio_buffer_enqueue_dmabuf()
authorBenoît Monin <benoit.monin@bootlin.com>
Wed, 1 Apr 2026 15:24:58 +0000 (17:24 +0200)
committerJonathan Cameron <jic23@kernel.org>
Fri, 15 May 2026 11:01:37 +0000 (12:01 +0100)
commita093999355084bdbfe6e97f1dd232e58a1525f0b
tree4b871af36d639665526916ed66b029db466bc441
parenta9aba21a539c668a66b58eeb08ad3909e5a54c2a
iio: buffer: Fix DMA fence leak in iio_buffer_enqueue_dmabuf()

iio_buffer_enqueue_dmabuf() allocates a struct iio_dma_fence (104 bytes,
kmalloc-128) via kmalloc_obj()+dma_fence_init(), which sets the initial
kref to 1.  It then calls dma_resv_add_fence() which takes a second
reference (kref=2), and stores a raw pointer in block->fence.

On the success path the function returns without calling dma_fence_put()
to release the initial reference, so every buffer enqueue permanently
leaks one kmalloc-128 allocation.

The iio_buffer_cleanup() work item only releases the temporary reference
taken during completion signalling by iio_buffer_signal_dmabuf_done();
the initial reference from dma_fence_init() is never released.

With four iio_rwdev instances at 240kHz and 512 samples per buffer,
this produces ~1875 kmalloc-128 allocations per second matching the
observed slab growth exactly. A test with ftrace confirmed that the
dma_fence_destroy event was never triggered.

Fix by calling dma_fence_put() after dma_resv_add_fence(), transferring
ownership of the fence to the DMA reservation object. The DMA fence then
gets properly discarded after being signalled.

Fixes: 3e26d9f08fbe0 ("iio: core: Add new DMABUF interface infrastructure")
Originally-by: James Nuss <jamesnuss@nanometrics.ca>
Signed-off-by: Benoît Monin <benoit.monin@bootlin.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
drivers/iio/industrialio-buffer.c