linux-kernel - drm/nouveau/core/memory: kmemleak 684 new suspected memory leaks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190517061340.GA709@jagdpanzerIV>
Date:   Fri, 17 May 2019 15:13:40 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Ben Skeggs <bskeggs@...hat.com>, David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>
Cc:     dri-devel@...ts.freedesktop.org, nouveau@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: drm/nouveau/core/memory: kmemleak 684 new suspected memory leaks

Hello,

5.1.0-next-20190517

I'm looking at quite a lot of kmemleak reports coming from
drm/nouveau/core/memory, all of which are:

    unreferenced object 0xffff8deec27c4ac0 (size 16):
      comm "Web Content", pid 5309, jiffies 4309675011 (age 68.076s)
      hex dump (first 16 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<0000000081f2894f>] nvkm_memory_tags_get+0x8e/0x130
        [<000000007cd7c0bc>] gf100_vmm_valid+0x196/0x2f0
        [<0000000070cc6d67>] nvkm_vmm_map+0xa8/0x360
        [<00000000ab678644>] nvkm_vram_map+0x48/0x50
        [<00000000d8176378>] nvkm_uvmm_mthd+0x658/0x770
        [<00000000463fca5a>] nvkm_ioctl+0xdf/0x177
        [<000000000afc4996>] nvif_object_mthd+0xd4/0x100
        [<000000002f7a7385>] nvif_vmm_map+0xeb/0x100
        [<00000000ef2537ed>] nouveau_mem_map+0x79/0xd0
        [<0000000014ddc0cf>] nouveau_vma_new+0x19d/0x1c0
        [<00000000f99888a1>] nouveau_gem_object_open+0xd4/0x140
        [<000000009cd25861>] drm_gem_handle_create_tail+0xe3/0x160
        [<00000000191784d9>] nouveau_gem_ioctl_new+0x6e/0xd0
        [<00000000159678df>] drm_ioctl_kernel+0x8c/0xd0
        [<00000000fbaa6154>] drm_ioctl+0x1c4/0x360
        [<000000006833fe15>] nouveau_drm_ioctl+0x63/0xb0

Wondering if those are real leaks or just false positives.

For now I marked `tags' as kmemleak_not_leak(); but most
likely it's utterly wrong.

Any thoughts?

---
 drivers/gpu/drm/nouveau/nvkm/core/memory.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/core/memory.c b/drivers/gpu/drm/nouveau/nvkm/core/memory.c
index e85a08ecd9da..cd46f54c5c32 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/memory.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/memory.c
@@ -25,6 +25,7 @@
 #include <core/mm.h>
 #include <subdev/fb.h>
 #include <subdev/instmem.h>
+#include <linux/kmemleak.h>
 
 void
 nvkm_memory_tags_put(struct nvkm_memory *memory, struct nvkm_device *device,
@@ -92,6 +93,7 @@ nvkm_memory_tags_get(struct nvkm_memory *memory, struct nvkm_device *device,
 
 	refcount_set(&tags->refcount, 1);
 	mutex_unlock(&fb->subdev.mutex);
+	kmemleak_not_leak(tags);
 	*ptags = tags;
 	return 0;
 }
-- 
2.21.0