On Wed, Nov 28, 2018 at 05:08:45PM -0500, Qian Cai wrote: > Kmemleak does not play well with KASAN (tested on both HPE Apollo 70 and > Huawei TaiShan 2280 aarch64 servers). > > After calling start_kernel()->setup_arch()->kasan_init(), kmemleak early > log buffer went from something like 280 to 260000 which caused kmemleak > disabled and crash dump memory reservation failed. The multitude of > kmemleak_alloc() calls is from nested loops while KASAN is setting up > full memory mappings, so let early kmemleak allocations skip those > memblock_alloc_internal() calls came from kasan_init() given that those > early KASAN memory mappings should not reference to other memory. > Hence, no kmemleak false positives. > > kasan_init > kasan_map_populate [1] > kasan_pgd_populate [2] > kasan_pud_populate [3] > kasan_pmd_populate [4] > kasan_pte_populate [5] > kasan_alloc_zeroed_page > memblock_alloc_try_nid > memblock_alloc_internal > kmemleak_alloc > > [1] for_each_memblock(memory, reg) > [2] while (pgdp++, addr = next, addr != end) > [3] while (pudp++, addr = next, addr != end && pud_none(READ_ONCE(*pudp))) > [4] while (pmdp++, addr = next, addr != end && pmd_none(READ_ONCE(*pmdp))) > [5] while (ptep++, addr = next, addr != end && pte_none(READ_ONCE(*ptep))) > > Signed-off-by: Qian Cai <cai@xxxxxx> Acked-by: Catalin Marinas <catalin.marinas@xxxxxxx> (for both the kmemleak and arm64 changes)
