Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Qian Cai <cai@lca.pw>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH] powerpc/kvm: silence kmemleak false positives
Date:   Mon, 11 May 2020 07:43:30 -0400
Message-Id: <44807D44-98D9-431C-9266-08014C4B47F6@lca.pw>
References: <87y2pybu38.fsf@mpe.ellerman.id.au>
Cc:     paulus@ozlabs.org, benh@kernel.crashing.org,
        catalin.marinas@arm.com, kvm-ppc@vger.kernel.org,
        linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <87y2pybu38.fsf@mpe.ellerman.id.au>
To:     Michael Ellerman <mpe@ellerman.id.au>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On May 11, 2020, at 7:15 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>=20
> There is kmemleak_alloc_phys(), which according to the docs can be used
> for tracking a phys address.
>=20
> Did you try that?

Caitlin, feel free to give your thoughts here.

My understanding is that it seems the doc is a bit misleading. kmemleak_allo=
c_phys() is to allocate kmemleak objects for a physical address range, so  k=
memleak could scan those memory pointers within for possible referencing oth=
er memory. It was only used in memblock so far, but those new memory allocat=
ions here contain no reference to other memory.

In this case, we have already had kmemleak objects for those memory allocati=
on. It is just that other pointers reference those memory by their physical a=
ddress which is a known kmemleak limitation won=E2=80=99t be able to track t=
he the connection. Thus, we always use kmemleak_ignore() to not reporting th=
ose as leaks and don=E2=80=99t scan those because they do not contain other m=
emory reference.=