diff options
author | Charan Teja Reddy <charante@codeaurora.org> | 2021-07-23 18:01:08 +0530 |
---|---|---|
committer | Christian König <christian.koenig@amd.com> | 2021-08-16 14:07:56 +0200 |
commit | f492283b157053e9555787262f058ae33096f568 (patch) | |
tree | dec4d9318c3411c6bb67537f6b65ed983e0caa3b /mm/slab.h | |
parent | 992c238188a83befa0094a8c00bfead31aa302ed (diff) | |
download | linux-f492283b157053e9555787262f058ae33096f568.tar.gz linux-f492283b157053e9555787262f058ae33096f568.tar.bz2 linux-f492283b157053e9555787262f058ae33096f568.zip |
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().
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>
Diffstat (limited to 'mm/slab.h')
0 files changed, 0 insertions, 0 deletions