lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <44807D44-98D9-431C-9266-08014C4B47F6@lca.pw>
Date:   Mon, 11 May 2020 07:43:30 -0400
From:   Qian Cai <cai@....pw>
To:     Michael Ellerman <mpe@...erman.id.au>
Cc:     paulus@...abs.org, benh@...nel.crashing.org,
        catalin.marinas@....com, 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 May 11, 2020, at 7:15 AM, Michael Ellerman <mpe@...erman.id.au> wrote:
> 
> There is kmemleak_alloc_phys(), which according to the docs can be used
> for tracking a phys address.
> 
> 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_alloc_phys() is to allocate kmemleak objects for a physical address range, so  kmemleak could scan those memory pointers within for possible referencing other memory. It was only used in memblock so far, but those new memory allocations here contain no reference to other memory.

In this case, we have already had kmemleak objects for those memory allocation. It is just that other pointers reference those memory by their physical address which is a known kmemleak limitation won’t be able to track the the connection. Thus, we always use kmemleak_ignore() to not reporting those as leaks and don’t scan those because they do not contain other memory reference.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ