summaryrefslogtreecommitdiff
path: root/scripts/objdiff
diff options
context:
space:
mode:
authorBenoît Monin <benoit.monin@bootlin.com>2026-04-01 17:24:58 +0200
committerJonathan Cameron <jic23@kernel.org>2026-05-15 12:01:37 +0100
commita093999355084bdbfe6e97f1dd232e58a1525f0b (patch)
tree4b871af36d639665526916ed66b029db466bc441 /scripts/objdiff
parenta9aba21a539c668a66b58eeb08ad3909e5a54c2a (diff)
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>
Diffstat (limited to 'scripts/objdiff')
0 files changed, 0 insertions, 0 deletions