Re: kmemleak panic

From: Prateek Patel
Date: Tue Jan 22 2019 - 03:20:38 EST



On 1/21/2019 7:24 PM, Marc Gonzalez wrote:
On 21/01/2019 14:35, Rob Herring wrote:

On Mon, Jan 21, 2019 at 6:19 AM Robin Murphy wrote:
On 21/01/2019 11:57, Marc Gonzalez wrote:
[...]
# echo dump=0xffffffc021e00000 > /sys/kernel/debug/kmemleak
kmemleak: Object 0xffffffc021e00000 (size 2097152):
kmemleak: comm "swapper/0", pid 0, jiffies 4294892296
kmemleak: min_count = 0
kmemleak: count = 0
kmemleak: flags = 0x1
kmemleak: checksum = 0
kmemleak: backtrace:
kmemleak_alloc_phys+0x48/0x60
memblock_alloc_range_nid+0x8c/0xa4
memblock_alloc_base_nid+0x4c/0x60
__memblock_alloc_base+0x3c/0x4c
early_init_dt_alloc_reserved_memory_arch+0x54/0xa4
fdt_init_reserved_mem+0x308/0x3ec
early_init_fdt_scan_reserved_mem+0x88/0xb0
arm64_memblock_init+0x1dc/0x254
setup_arch+0x1c8/0x4ec
start_kernel+0x84/0x44c
0xffffffffffffffff
OK, so via the __va(phys) call in kmemleak_alloc_phys(), you end up with
the linear map address of a no-map reservation, which unsurprisingly
turns out not to be mapped. Is there a way to tell kmemleak that it
can't scan within a particular object?

Yes, kmemleak_no_scan() do this which is done in patch https://patchwork.ozlabs.org/patch/995367/

This was done to avoid kmemleak scanning on the blocks which are nomaped and should not have linear mapping created in kernel page table.

There was this patch posted[1]. I never got a reply, so it hasn't been applied.

Rob

https://patchwork.ozlabs.org/patch/995367/
It is worth noting that the author's email address appears to be dead.
<schowdary@xxxxxxxxxx>: host hqemgate08.nvidia.com[216.228.121.117] said:
550 #5.1.0 Address rejected. (in reply to RCPT TO command)

Adding a few nvidia devs for comment.