On 08/11/2016 06:54 PM, Catalin Marinas wrote:
> On Thu, Aug 11, 2016 at 05:20:51PM +0530, Vignesh R wrote:
>> I see the below message from kmemleak when booting linux-next on AM335x
>> GP EVM and DRA7 EVM
>
> Can you also reproduce it with 4.8-rc1?
>
>> [ 0.803934] kmemleak: Cannot insert 0xff7f1000 into the object search tree (overlaps existing)
>> [ 0.803950] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc1-next-20160809 #497
>> [ 0.803958] Hardware name: Generic DRA72X (Flattened Device Tree)
>> [ 0.803979] [<c0110104>] (unwind_backtrace) from [<c010c24c>] (show_stack+0x10/0x14)
>> [ 0.803994] [<c010c24c>] (show_stack) from [<c0490df0>] (dump_stack+0xac/0xe0)
>> [ 0.804010] [<c0490df0>] (dump_stack) from [<c0296f88>] (create_object+0x214/0x278)
>> [ 0.804025] [<c0296f88>] (create_object) from [<c07c770c>] (kmemleak_alloc_percpu+0x54/0xc0)
>> [ 0.804038] [<c07c770c>] (kmemleak_alloc_percpu) from [<c025fb08>] (pcpu_alloc+0x368/0x5fc)
>> [ 0.804052] [<c025fb08>] (pcpu_alloc) from [<c0b1bfbc>] (crash_notes_memory_init+0x10/0x40)
>> [ 0.804064] [<c0b1bfbc>] (crash_notes_memory_init) from [<c010188c>] (do_one_initcall+0x3c/0x178)
>> [ 0.804075] [<c010188c>] (do_one_initcall) from [<c0b00e98>] (kernel_init_freeable+0x1fc/0x2c8)
>> [ 0.804086] [<c0b00e98>] (kernel_init_freeable) from [<c07c66b0>] (kernel_init+0x8/0x114)
>> [ 0.804098] [<c07c66b0>] (kernel_init) from [<c0107910>] (ret_from_fork+0x14/0x24)
>
> This is the allocation stack trace, going via pcpu_alloc().
>
>> [ 0.804106] kmemleak: Kernel memory leak detector disabled
>> [ 0.804113] kmemleak: Object 0xfe800000 (size 16777216):
>> [ 0.804121] kmemleak: comm "swapper/0", pid 0, jiffies 4294937296
>> [ 0.804127] kmemleak: min_count = -1
>> [ 0.804132] kmemleak: count = 0
>> [ 0.804138] kmemleak: flags = 0x5
>> [ 0.804143] kmemleak: checksum = 0
>> [ 0.804149] kmemleak: backtrace:
>> [ 0.804155] [<c0b26a90>] cma_declare_contiguous+0x16c/0x214
>> [ 0.804170] [<c0b3c9c0>] dma_contiguous_reserve_area+0x30/0x64
>> [ 0.804183] [<c0b3ca74>] dma_contiguous_reserve+0x80/0x94
>> [ 0.804195] [<c0b06810>] arm_memblock_init+0x130/0x184
>> [ 0.804207] [<c0b04214>] setup_arch+0x590/0xc08
>> [ 0.804217] [<c0b00940>] start_kernel+0x58/0x3b4
>> [ 0.804227] [<8000807c>] 0x8000807c
>> [ 0.804237] [<ffffffff>] 0xffffffff
>
> This seems to be the original object that was allocated via
> cma_declare_contiguous(): 16MB range from 0xfe800000 to 0xff800000.
> Since the pointer returned by pcpu_alloc is 0xff7f1000 falls in the 16MB
> CMA range, kmemleak gets confused (it doesn't allow overlapping
> objects).
>
> So what I think goes wrong is that the kmemleak_alloc(__va(found)) call
> in memblock_alloc_range_nid() doesn't get the right value for the VA of
> the CMA block. The memblock_alloc_range() call in
> cma_declare_contiguous() asks for memory above high_memory, hence on a
> 32-bit architecture with highmem enabled, __va() use is not really
> valid, returning the wrong address. The existing kmemleak object is
> bogus, it shouldn't have been created in the first place.
>
> Now I'm trying to figure out how to differentiate between lowmem
> memblocks and highmem ones. Ignoring the kmemleak_alloc() calls
> altogether in mm/memblock.c is probably not an option as it would lead
> to lots of false positives.
>
But cma_declare_contiguous() calls -
/*
* kmemleak scans/reads tracked objects for pointers to other
* objects but this address isn't mapped and accessible
*/
kmemleak_ignore(phys_to_virt(addr));
Does it means above code is incorrect also?
It's a little bit strange that this can be seen only now, because
commit 95b0e655f9 ("ARM: mm: don't limit default CMA region only to low memor")
is pretty old.
--
regards,
-grygorii
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>