Repository files (latest commit first)

Filename	Latest commit message	Latest commit date
Charan Teja Reddy a453bdb6a8 dma-buf: WARN on dmabuf release with pending attachments ... 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(). Change-Id: Ia58b41500be943fe3c2da3eb0f5480ae99715de2 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>		2021-09-05 22:11:56 -07:00
..
dma-buf-ref.c
dma-buf.c	dma-buf: WARN on dmabuf release with pending attachments	2021-09-05 22:11:56 -07: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
sync_trace.h
udmabuf.c