Repository files (latest commit first)

Filename	Latest commit message	Latest commit date
Charan Teja Reddy 46a25b7a25 dma-buf: WARN on dmabuf release with pending attachments ... [ Upstream commit f492283b157053e9555787262f058ae33096f568 ] It is expected from the clients to follow the below steps on an imported dmabuf fd: a) dmabuf = dma_buf_get(fd) // Get the dmabuf from fd b) dma_buf_attach(dmabuf); // Clients attach to the dmabuf o Here the kernel does some slab allocations, say for dma_buf_attachment and may be some other slab allocation in the dmabuf->ops->attach(). c) Client may need to do dma_buf_map_attachment(). d) Accordingly dma_buf_unmap_attachment() should be called. e) dma_buf_detach () // Clients detach to the dmabuf. o Here the slab allocations made in b) are freed. f) dma_buf_put(dmabuf) // Can free the dmabuf if it is the last reference. Now say an erroneous client failed at step c) above thus it directly called dma_buf_put(), step f) above. Considering that it may be the last reference to the dmabuf, buffer will be freed with pending attachments left to the dmabuf which can show up as the 'memory leak'. This should at least be reported as the WARN(). Signed-off-by: Charan Teja Reddy <charante@codeaurora.org> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/1627043468-16381-1-git-send-email-charante@codeaurora.org Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>		2021-11-17 09:48:27 +01:00
..
dma-buf.c	dma-buf: WARN on dmabuf release with pending attachments	2021-11-17 09:48:27 +01:00
dma-fence-array.c
dma-fence-chain.c
dma-fence.c
dma-resv.c	dma-buf/dma-resv: Respect num_fences when initializing the shared fence list.	2020-12-30 11:51:46 +01:00
Kconfig
Makefile
selftest.c
selftest.h
selftests.h
seqno-fence.c
st-dma-fence.c
sw_sync.c
sync_debug.c
sync_debug.h
sync_file.c	dma-buf/sync_file: Don't leak fences on merge failure	2021-07-25 14:35:15 +02:00
sync_trace.h
udmabuf.c