[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200511112829.GB19176@gaia>
Date: Mon, 11 May 2020 12:28:30 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Michael Ellerman <mpe@...erman.id.au>
Cc: Qian Cai <cai@....pw>, paulus@...abs.org, benh@...nel.crashing.org,
kvm-ppc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] powerpc/kvm: silence kmemleak false positives
On Mon, May 11, 2020 at 09:15:55PM +1000, Michael Ellerman wrote:
> Qian Cai <cai@....pw> writes:
> > kvmppc_pmd_alloc() and kvmppc_pte_alloc() allocate some memory but then
> > pud_populate() and pmd_populate() will use __pa() to reference the newly
> > allocated memory. The same is in xive_native_provision_pages().
> >
> > Since kmemleak is unable to track the physical memory resulting in false
> > positives, silence those by using kmemleak_ignore().
>
> There is kmemleak_alloc_phys(), which according to the docs can be used
> for tracking a phys address.
This won't help. While kmemleak_alloc_phys() allows passing a physical
address, it doesn't track physical address references to this object. It
still expects VA pointing to it, otherwise the object would be reported
as a leak.
We currently only call this from the memblock code with a min_count of
0, meaning it will not be reported as a leak if no references are found.
We don't have this issue with page tables on other architectures since
most of them use whole page allocations which aren't tracked by
kmemleak. These powerpc functions use kmem_cache_alloc() which would be
tracked automatically by kmemleak. While we could add a phys alias to
kmemleak (another search tree), I think the easiest is as per Qian's
patch, just ignore those objects.
--
Catalin
Powered by blists - more mailing lists