re: kern/56826: Kernel memory leak with Nvidia GPU

[matthew green <mrg%eterna.com.au@localhost>]

The following reply was made to PR kern/56826; it has been noted by GNATS.

From: matthew green <mrg%eterna.com.au@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
    netbsd-bugs%netbsd.org@localhost
Subject: re: kern/56826: Kernel memory leak with Nvidia GPU
Date: Tue, 31 May 2022 13:31:41 +1000

 with Taylor's new kmem probes and a little investigation i've
 narrowed down at least two leaks i believe.
 
 nvkm_mem_new_host() has two paths that allocate "struct nvkm_mem
 *mem":  one that copies a dmamap from the caller via ioctl-like
 arguments, or, one that creates one freshly.  both of them are
 setup to use the same dtor via nvkm_mem_dma.dtor, set to
 nvkm_mem_dtor() which only does something if "mem->mem" is non
 NULL.  however, only the second path sets "mem->mem", so this
 dtor call does not free the allocation, and we leak it.
 
 a simple hack to free is triggering crashes so it's not quite as
 simple as it may appear here.
 
 the second leak appears to be the second path, which does a whole
 bus_dma setup phase:  bus_dmamem_alloc(), bus_dmamap_create(),
 bus_dmamap_load_raw().  however, there's no bus_dmamap_destroy()
 that isn't in this setup error path, so, allocations created here
 are also leaking i believe (i haven't confirmed this yet.)
 
 for the second one, i'm wondering why we'd be doing create and
 destroy so frequently -- shouldn't set up a busdma in device
 init, and then using it, and destroy in device tear down?
 
 
 .mrg.