From: Catalin Marinas <catalin.marinas@arm.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Qian Cai <cai@lca.pw>,
paulus@ozlabs.org, benh@kernel.crashing.org,
kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] powerpc/kvm: silence kmemleak false positives
Date: Mon, 11 May 2020 12:28:30 +0100 [thread overview]
Message-ID: <20200511112829.GB19176@gaia> (raw)
In-Reply-To: <87y2pybu38.fsf@mpe.ellerman.id.au>
On Mon, May 11, 2020 at 09:15:55PM +1000, Michael Ellerman wrote:
> Qian Cai <cai@lca.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
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: linux-kernel@vger.kernel.org, kvm-ppc@vger.kernel.org,
Qian Cai <cai@lca.pw>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/kvm: silence kmemleak false positives
Date: Mon, 11 May 2020 12:28:30 +0100 [thread overview]
Message-ID: <20200511112829.GB19176@gaia> (raw)
In-Reply-To: <87y2pybu38.fsf@mpe.ellerman.id.au>
On Mon, May 11, 2020 at 09:15:55PM +1000, Michael Ellerman wrote:
> Qian Cai <cai@lca.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
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Qian Cai <cai@lca.pw>,
paulus@ozlabs.org, benh@kernel.crashing.org,
kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] powerpc/kvm: silence kmemleak false positives
Date: Mon, 11 May 2020 11:28:30 +0000 [thread overview]
Message-ID: <20200511112829.GB19176@gaia> (raw)
In-Reply-To: <87y2pybu38.fsf@mpe.ellerman.id.au>
On Mon, May 11, 2020 at 09:15:55PM +1000, Michael Ellerman wrote:
> Qian Cai <cai@lca.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
next prev parent reply other threads:[~2020-05-11 11:28 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-09 1:55 [PATCH] powerpc/kvm: silence kmemleak false positives Qian Cai
2020-05-09 1:55 ` Qian Cai
2020-05-09 1:55 ` Qian Cai
2020-05-11 11:15 ` Michael Ellerman
2020-05-11 11:15 ` Michael Ellerman
2020-05-11 11:15 ` Michael Ellerman
2020-05-11 11:28 ` Catalin Marinas [this message]
2020-05-11 11:28 ` Catalin Marinas
2020-05-11 11:28 ` Catalin Marinas
2020-05-13 4:00 ` Michael Ellerman
2020-05-13 4:00 ` Michael Ellerman
2020-05-13 4:00 ` Michael Ellerman
2020-05-11 11:43 ` Qian Cai
2020-05-11 11:43 ` Qian Cai
2020-05-11 11:43 ` Qian Cai
2020-05-12 14:17 ` Catalin Marinas
2020-05-12 14:17 ` Catalin Marinas
2020-05-12 14:17 ` Catalin Marinas
2020-05-13 4:05 ` Michael Ellerman
2020-05-13 4:05 ` Michael Ellerman
2020-05-13 4:05 ` Michael Ellerman
2020-05-13 6:24 ` Qian Cai
2020-05-13 6:24 ` Qian Cai
2020-05-13 6:24 ` Qian Cai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200511112829.GB19176@gaia \
--to=catalin.marinas@arm.com \
--cc=benh@kernel.crashing.org \
--cc=cai@lca.pw \
--cc=kvm-ppc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.