Hi Martin,
Am Mittwoch, den 20.05.2020, 12:10 +0200 schrieb Martin Fuzzey:
When using mmap() on a prime imported buffer allocated by a different driver (such as imx-drm) the later munmap() does not correctly decrement the refcount of the original enaviv_gem_object, leading to a leak.
Signed-off-by: Martin Fuzzey martin.fuzzey@flowbird.group Cc: stable@vger.kernel.org
What's the use-case where you did hit this issue? mmap'ing of imported buffers through the etnaviv DRM device is currently not well defined and I was pondering the idea of forbidding it completely by not returning a mmap offset for those objects.
Regards, Lucas
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c index f24dd21..28a01b8 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c @@ -93,7 +93,25 @@ static void *etnaviv_gem_prime_vmap_impl(struct etnaviv_gem_object *etnaviv_obj) static int etnaviv_gem_prime_mmap_obj(struct etnaviv_gem_object *etnaviv_obj, struct vm_area_struct *vma) {
- return dma_buf_mmap(etnaviv_obj->base.dma_buf, vma, 0);
- int ret;
- ret = dma_buf_mmap(etnaviv_obj->base.dma_buf, vma, 0);
- /* drm_gem_mmap_obj() has already been called before this function
* and has incremented our refcount, expecting it to be decremented* on unmap() via drm_gem_vm_close().* However dma_buf_mmap() invokes drm_gem_cma_prime_mmap()* that ends up updating the vma->vma_private_data to point to the* dma_buf's gem object.* Hence our gem object here will not have its refcount decremented* when userspace does unmap().* So decrement the refcount here to avoid a memory leak if the dma* buf mapping was successful.*/- if (!ret)
drm_gem_object_put_unlocked(&etnaviv_obj->base);- return ret;
} static const struct etnaviv_gem_ops etnaviv_gem_prime_ops = {