LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Alexey Kardashevskiy <aik@ozlabs.ru>, linuxppc-dev@lists.ozlabs.org
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>, Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH kernel] powerpc/xive: Ignore kmemleak false positives
Date: Fri, 12 Jun 2020 22:43:22 +1000	[thread overview]
Message-ID: <87a718fo9h.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <20200612043303.84894-1-aik@ozlabs.ru>

Alexey Kardashevskiy <aik@ozlabs.ru> writes:
> xive_native_provision_pages() allocates memory and passes the pointer to
> OPAL so kmemleak cannot find the pointer usage in the kernel memory and
> produces a false positive report (below) (even if the kernel did scan
> OPAL memory, it is unable to deal with __pa() addresses anyway).
>
> This silences the warning.
>
> unreferenced object 0xc000200350c40000 (size 65536):
>   comm "qemu-system-ppc", pid 2725, jiffies 4294946414 (age 70776.530s)
>   hex dump (first 32 bytes):
>     02 00 00 00 50 00 00 00 00 00 00 00 00 00 00 00  ....P...........
>     01 00 08 07 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace:
>     [<0000000081ff046c>] xive_native_alloc_vp_block+0x120/0x250
>     [<00000000d555d524>] kvmppc_xive_compute_vp_id+0x248/0x350 [kvm]
>     [<00000000d69b9c9f>] kvmppc_xive_connect_vcpu+0xc0/0x520 [kvm]
>     [<000000006acbc81c>] kvm_arch_vcpu_ioctl+0x308/0x580 [kvm]
>     [<0000000089c69580>] kvm_vcpu_ioctl+0x19c/0xae0 [kvm]
>     [<00000000902ae91e>] ksys_ioctl+0x184/0x1b0
>     [<00000000f3e68bd7>] sys_ioctl+0x48/0xb0
>     [<0000000001b2c127>] system_call_exception+0x124/0x1f0
>     [<00000000d2b2ee40>] system_call_common+0xe8/0x214
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>
> Does kmemleak actually check the OPAL memory?

No it shouldn't.

The memory used by OPAL should all be reserved in the device tree. That
means we never give it to any of the Linux memory allocators, and
therefore kmemleak will never see an allocation from those areas and add
that area to its list of areas to scan.

At least that's my understanding of how kmemleak works.

> Because if it did, we would still have a warning as kmemleak does not
> trace __pa() addresses anyway.

Right.

I think this patch is an OK solution.

It's kind of odd that we donate pages and don't keep track of them. But
they're used by xive until it's reset, and we don't do that until we
kexec, at which point we don't need to know about them anyway.

cheers

  reply	other threads:[~2020-06-12 12:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-12  4:33 [PATCH kernel] powerpc/xive: Ignore kmemleak false positives Alexey Kardashevskiy
2020-06-12 12:43 ` Michael Ellerman [this message]
2020-06-26  4:45 ` Michael Ellerman

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=87a718fo9h.fsf@mpe.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=aik@ozlabs.ru \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=paulus@samba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox