* [PATCH] powerpc/kvm: silence kmemleak false positives
@ 2020-05-09 1:55 ` Qian Cai
0 siblings, 0 replies; 24+ messages in thread
From: Qian Cai @ 2020-05-09 1:55 UTC (permalink / raw)
To: mpe
Cc: paulus, benh, catalin.marinas, kvm-ppc, linuxppc-dev,
linux-kernel, Qian Cai
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().
unreferenced object 0xc000201c382a1000 (size 4096):
comm "qemu-kvm", pid 124828, jiffies 4295733767 (age 341.250s)
hex dump (first 32 bytes):
c0 00 20 09 f4 60 03 87 c0 00 20 10 72 a0 03 87 .. ..`.... .r...
c0 00 20 0e 13 a0 03 87 c0 00 20 1b dc c0 03 87 .. ....... .....
backtrace:
[<000000004cc2790f>] kvmppc_create_pte+0x838/0xd20 [kvm_hv]
kvmppc_pmd_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:366
(inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:590
[<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
[<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
[<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
[<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
[<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
[<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
[<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
[<0000000048155cd6>] ksys_ioctl+0xd8/0x130
[<0000000041ffeaa7>] sys_ioctl+0x28/0x40
[<000000004afc4310>] system_call_exception+0x114/0x1e0
[<00000000fb70a873>] system_call_common+0xf0/0x278
unreferenced object 0xc0002001f0c03900 (size 256):
comm "qemu-kvm", pid 124830, jiffies 4295735235 (age 326.570s)
hex dump (first 32 bytes):
c0 00 20 10 fa a0 03 87 c0 00 20 10 fa a1 03 87 .. ....... .....
c0 00 20 10 fa a2 03 87 c0 00 20 10 fa a3 03 87 .. ....... .....
backtrace:
[<0000000023f675b8>] kvmppc_create_pte+0x854/0xd20 [kvm_hv]
kvmppc_pte_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:356
(inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:593
[<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
[<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
[<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
[<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
[<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
[<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
[<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
[<0000000048155cd6>] ksys_ioctl+0xd8/0x130
[<0000000041ffeaa7>] sys_ioctl+0x28/0x40
[<000000004afc4310>] system_call_exception+0x114/0x1e0
[<00000000fb70a873>] system_call_common+0xf0/0x278
unreferenced object 0xc000201b53e90000 (size 65536):
comm "qemu-kvm", pid 124557, jiffies 4295650285 (age 364.370s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000acc2fb77>] xive_native_alloc_vp_block+0x168/0x210
xive_native_provision_pages at arch/powerpc/sysdev/xive/native.c:645
(inlined by) xive_native_alloc_vp_block at arch/powerpc/sysdev/xive/native.c:674
[<000000004d5c7964>] kvmppc_xive_compute_vp_id+0x20c/0x3b0 [kvm]
[<0000000055317cd2>] kvmppc_xive_connect_vcpu+0xa4/0x4a0 [kvm]
[<0000000093dfc014>] kvm_arch_vcpu_ioctl+0x388/0x508 [kvm]
[<00000000d25aea0f>] kvm_vcpu_ioctl+0x15c/0x950 [kvm]
[<0000000048155cd6>] ksys_ioctl+0xd8/0x130
[<0000000041ffeaa7>] sys_ioctl+0x28/0x40
[<000000004afc4310>] system_call_exception+0x114/0x1e0
[<00000000fb70a873>] system_call_common+0xf0/0x278
Signed-off-by: Qian Cai <cai@lca.pw>
---
arch/powerpc/kvm/book3s_64_mmu_radix.c | 16 ++++++++++++++--
arch/powerpc/sysdev/xive/native.c | 4 ++++
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c
index aa12cd4078b3..bc6c1aa3d0e9 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -353,7 +353,13 @@ static struct kmem_cache *kvm_pmd_cache;
static pte_t *kvmppc_pte_alloc(void)
{
- return kmem_cache_alloc(kvm_pte_cache, GFP_KERNEL);
+ pte_t *pte;
+
+ pte = kmem_cache_alloc(kvm_pte_cache, GFP_KERNEL);
+ /* pmd_populate() will only reference _pa(pte). */
+ kmemleak_ignore(pte);
+
+ return pte;
}
static void kvmppc_pte_free(pte_t *ptep)
@@ -363,7 +369,13 @@ static void kvmppc_pte_free(pte_t *ptep)
static pmd_t *kvmppc_pmd_alloc(void)
{
- return kmem_cache_alloc(kvm_pmd_cache, GFP_KERNEL);
+ pmd_t *pmd;
+
+ pmd = kmem_cache_alloc(kvm_pmd_cache, GFP_KERNEL);
+ /* pud_populate() will only reference _pa(pmd). */
+ kmemleak_ignore(pmd);
+
+ return pmd;
}
static void kvmppc_pmd_free(pmd_t *pmdp)
diff --git a/arch/powerpc/sysdev/xive/native.c b/arch/powerpc/sysdev/xive/native.c
index 5218fdc4b29a..2d19f28967a6 100644
--- a/arch/powerpc/sysdev/xive/native.c
+++ b/arch/powerpc/sysdev/xive/native.c
@@ -18,6 +18,7 @@
#include <linux/delay.h>
#include <linux/cpumask.h>
#include <linux/mm.h>
+#include <linux/kmemleak.h>
#include <asm/machdep.h>
#include <asm/prom.h>
@@ -647,6 +648,9 @@ static bool xive_native_provision_pages(void)
pr_err("Failed to allocate provisioning page\n");
return false;
}
+ /* Kmemleak is unable to track the physical address. */
+ kmemleak_ignore(p);
+
opal_xive_donate_page(chip, __pa(p));
}
return true;
--
2.21.0 (Apple Git-122.2)
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH] powerpc/kvm: silence kmemleak false positives
@ 2020-05-09 1:55 ` Qian Cai
0 siblings, 0 replies; 24+ messages in thread
From: Qian Cai @ 2020-05-09 1:55 UTC (permalink / raw)
To: mpe; +Cc: linux-kernel, kvm-ppc, Qian Cai, catalin.marinas, linuxppc-dev
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().
unreferenced object 0xc000201c382a1000 (size 4096):
comm "qemu-kvm", pid 124828, jiffies 4295733767 (age 341.250s)
hex dump (first 32 bytes):
c0 00 20 09 f4 60 03 87 c0 00 20 10 72 a0 03 87 .. ..`.... .r...
c0 00 20 0e 13 a0 03 87 c0 00 20 1b dc c0 03 87 .. ....... .....
backtrace:
[<000000004cc2790f>] kvmppc_create_pte+0x838/0xd20 [kvm_hv]
kvmppc_pmd_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:366
(inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:590
[<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
[<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
[<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
[<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
[<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
[<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
[<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
[<0000000048155cd6>] ksys_ioctl+0xd8/0x130
[<0000000041ffeaa7>] sys_ioctl+0x28/0x40
[<000000004afc4310>] system_call_exception+0x114/0x1e0
[<00000000fb70a873>] system_call_common+0xf0/0x278
unreferenced object 0xc0002001f0c03900 (size 256):
comm "qemu-kvm", pid 124830, jiffies 4295735235 (age 326.570s)
hex dump (first 32 bytes):
c0 00 20 10 fa a0 03 87 c0 00 20 10 fa a1 03 87 .. ....... .....
c0 00 20 10 fa a2 03 87 c0 00 20 10 fa a3 03 87 .. ....... .....
backtrace:
[<0000000023f675b8>] kvmppc_create_pte+0x854/0xd20 [kvm_hv]
kvmppc_pte_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:356
(inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:593
[<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
[<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
[<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
[<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
[<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
[<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
[<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
[<0000000048155cd6>] ksys_ioctl+0xd8/0x130
[<0000000041ffeaa7>] sys_ioctl+0x28/0x40
[<000000004afc4310>] system_call_exception+0x114/0x1e0
[<00000000fb70a873>] system_call_common+0xf0/0x278
unreferenced object 0xc000201b53e90000 (size 65536):
comm "qemu-kvm", pid 124557, jiffies 4295650285 (age 364.370s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000acc2fb77>] xive_native_alloc_vp_block+0x168/0x210
xive_native_provision_pages at arch/powerpc/sysdev/xive/native.c:645
(inlined by) xive_native_alloc_vp_block at arch/powerpc/sysdev/xive/native.c:674
[<000000004d5c7964>] kvmppc_xive_compute_vp_id+0x20c/0x3b0 [kvm]
[<0000000055317cd2>] kvmppc_xive_connect_vcpu+0xa4/0x4a0 [kvm]
[<0000000093dfc014>] kvm_arch_vcpu_ioctl+0x388/0x508 [kvm]
[<00000000d25aea0f>] kvm_vcpu_ioctl+0x15c/0x950 [kvm]
[<0000000048155cd6>] ksys_ioctl+0xd8/0x130
[<0000000041ffeaa7>] sys_ioctl+0x28/0x40
[<000000004afc4310>] system_call_exception+0x114/0x1e0
[<00000000fb70a873>] system_call_common+0xf0/0x278
Signed-off-by: Qian Cai <cai@lca.pw>
---
arch/powerpc/kvm/book3s_64_mmu_radix.c | 16 ++++++++++++++--
arch/powerpc/sysdev/xive/native.c | 4 ++++
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c
index aa12cd4078b3..bc6c1aa3d0e9 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -353,7 +353,13 @@ static struct kmem_cache *kvm_pmd_cache;
static pte_t *kvmppc_pte_alloc(void)
{
- return kmem_cache_alloc(kvm_pte_cache, GFP_KERNEL);
+ pte_t *pte;
+
+ pte = kmem_cache_alloc(kvm_pte_cache, GFP_KERNEL);
+ /* pmd_populate() will only reference _pa(pte). */
+ kmemleak_ignore(pte);
+
+ return pte;
}
static void kvmppc_pte_free(pte_t *ptep)
@@ -363,7 +369,13 @@ static void kvmppc_pte_free(pte_t *ptep)
static pmd_t *kvmppc_pmd_alloc(void)
{
- return kmem_cache_alloc(kvm_pmd_cache, GFP_KERNEL);
+ pmd_t *pmd;
+
+ pmd = kmem_cache_alloc(kvm_pmd_cache, GFP_KERNEL);
+ /* pud_populate() will only reference _pa(pmd). */
+ kmemleak_ignore(pmd);
+
+ return pmd;
}
static void kvmppc_pmd_free(pmd_t *pmdp)
diff --git a/arch/powerpc/sysdev/xive/native.c b/arch/powerpc/sysdev/xive/native.c
index 5218fdc4b29a..2d19f28967a6 100644
--- a/arch/powerpc/sysdev/xive/native.c
+++ b/arch/powerpc/sysdev/xive/native.c
@@ -18,6 +18,7 @@
#include <linux/delay.h>
#include <linux/cpumask.h>
#include <linux/mm.h>
+#include <linux/kmemleak.h>
#include <asm/machdep.h>
#include <asm/prom.h>
@@ -647,6 +648,9 @@ static bool xive_native_provision_pages(void)
pr_err("Failed to allocate provisioning page\n");
return false;
}
+ /* Kmemleak is unable to track the physical address. */
+ kmemleak_ignore(p);
+
opal_xive_donate_page(chip, __pa(p));
}
return true;
--
2.21.0 (Apple Git-122.2)
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
2020-05-09 1:55 ` Qian Cai
(?)
@ 2020-05-11 11:15 ` Michael Ellerman
-1 siblings, 0 replies; 24+ messages in thread
From: Michael Ellerman @ 2020-05-11 11:15 UTC (permalink / raw)
To: Qian Cai
Cc: paulus, benh, catalin.marinas, kvm-ppc, linuxppc-dev,
linux-kernel, Qian Cai
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.
Did you try that?
cheers
> unreferenced object 0xc000201c382a1000 (size 4096):
> comm "qemu-kvm", pid 124828, jiffies 4295733767 (age 341.250s)
> hex dump (first 32 bytes):
> c0 00 20 09 f4 60 03 87 c0 00 20 10 72 a0 03 87 .. ..`.... .r...
> c0 00 20 0e 13 a0 03 87 c0 00 20 1b dc c0 03 87 .. ....... .....
> backtrace:
> [<000000004cc2790f>] kvmppc_create_pte+0x838/0xd20 [kvm_hv]
> kvmppc_pmd_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:366
> (inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:590
> [<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
> [<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
> [<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
> [<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
> [<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
> [<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
> [<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
> [<0000000048155cd6>] ksys_ioctl+0xd8/0x130
> [<0000000041ffeaa7>] sys_ioctl+0x28/0x40
> [<000000004afc4310>] system_call_exception+0x114/0x1e0
> [<00000000fb70a873>] system_call_common+0xf0/0x278
> unreferenced object 0xc0002001f0c03900 (size 256):
> comm "qemu-kvm", pid 124830, jiffies 4295735235 (age 326.570s)
> hex dump (first 32 bytes):
> c0 00 20 10 fa a0 03 87 c0 00 20 10 fa a1 03 87 .. ....... .....
> c0 00 20 10 fa a2 03 87 c0 00 20 10 fa a3 03 87 .. ....... .....
> backtrace:
> [<0000000023f675b8>] kvmppc_create_pte+0x854/0xd20 [kvm_hv]
> kvmppc_pte_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:356
> (inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:593
> [<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
> [<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
> [<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
> [<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
> [<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
> [<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
> [<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
> [<0000000048155cd6>] ksys_ioctl+0xd8/0x130
> [<0000000041ffeaa7>] sys_ioctl+0x28/0x40
> [<000000004afc4310>] system_call_exception+0x114/0x1e0
> [<00000000fb70a873>] system_call_common+0xf0/0x278
> unreferenced object 0xc000201b53e90000 (size 65536):
> comm "qemu-kvm", pid 124557, jiffies 4295650285 (age 364.370s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<00000000acc2fb77>] xive_native_alloc_vp_block+0x168/0x210
> xive_native_provision_pages at arch/powerpc/sysdev/xive/native.c:645
> (inlined by) xive_native_alloc_vp_block at arch/powerpc/sysdev/xive/native.c:674
> [<000000004d5c7964>] kvmppc_xive_compute_vp_id+0x20c/0x3b0 [kvm]
> [<0000000055317cd2>] kvmppc_xive_connect_vcpu+0xa4/0x4a0 [kvm]
> [<0000000093dfc014>] kvm_arch_vcpu_ioctl+0x388/0x508 [kvm]
> [<00000000d25aea0f>] kvm_vcpu_ioctl+0x15c/0x950 [kvm]
> [<0000000048155cd6>] ksys_ioctl+0xd8/0x130
> [<0000000041ffeaa7>] sys_ioctl+0x28/0x40
> [<000000004afc4310>] system_call_exception+0x114/0x1e0
> [<00000000fb70a873>] system_call_common+0xf0/0x278
>
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
> arch/powerpc/kvm/book3s_64_mmu_radix.c | 16 ++++++++++++++--
> arch/powerpc/sysdev/xive/native.c | 4 ++++
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c
> index aa12cd4078b3..bc6c1aa3d0e9 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
> @@ -353,7 +353,13 @@ static struct kmem_cache *kvm_pmd_cache;
>
> static pte_t *kvmppc_pte_alloc(void)
> {
> - return kmem_cache_alloc(kvm_pte_cache, GFP_KERNEL);
> + pte_t *pte;
> +
> + pte = kmem_cache_alloc(kvm_pte_cache, GFP_KERNEL);
> + /* pmd_populate() will only reference _pa(pte). */
> + kmemleak_ignore(pte);
> +
> + return pte;
> }
>
> static void kvmppc_pte_free(pte_t *ptep)
> @@ -363,7 +369,13 @@ static void kvmppc_pte_free(pte_t *ptep)
>
> static pmd_t *kvmppc_pmd_alloc(void)
> {
> - return kmem_cache_alloc(kvm_pmd_cache, GFP_KERNEL);
> + pmd_t *pmd;
> +
> + pmd = kmem_cache_alloc(kvm_pmd_cache, GFP_KERNEL);
> + /* pud_populate() will only reference _pa(pmd). */
> + kmemleak_ignore(pmd);
> +
> + return pmd;
> }
>
> static void kvmppc_pmd_free(pmd_t *pmdp)
> diff --git a/arch/powerpc/sysdev/xive/native.c b/arch/powerpc/sysdev/xive/native.c
> index 5218fdc4b29a..2d19f28967a6 100644
> --- a/arch/powerpc/sysdev/xive/native.c
> +++ b/arch/powerpc/sysdev/xive/native.c
> @@ -18,6 +18,7 @@
> #include <linux/delay.h>
> #include <linux/cpumask.h>
> #include <linux/mm.h>
> +#include <linux/kmemleak.h>
>
> #include <asm/machdep.h>
> #include <asm/prom.h>
> @@ -647,6 +648,9 @@ static bool xive_native_provision_pages(void)
> pr_err("Failed to allocate provisioning page\n");
> return false;
> }
> + /* Kmemleak is unable to track the physical address. */
> + kmemleak_ignore(p);
> +
> opal_xive_donate_page(chip, __pa(p));
> }
> return true;
> --
> 2.21.0 (Apple Git-122.2)
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
@ 2020-05-11 11:15 ` Michael Ellerman
0 siblings, 0 replies; 24+ messages in thread
From: Michael Ellerman @ 2020-05-11 11:15 UTC (permalink / raw)
To: Qian Cai
Cc: paulus, benh, catalin.marinas, kvm-ppc, linuxppc-dev,
linux-kernel, Qian Cai
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.
Did you try that?
cheers
> unreferenced object 0xc000201c382a1000 (size 4096):
> comm "qemu-kvm", pid 124828, jiffies 4295733767 (age 341.250s)
> hex dump (first 32 bytes):
> c0 00 20 09 f4 60 03 87 c0 00 20 10 72 a0 03 87 .. ..`.... .r...
> c0 00 20 0e 13 a0 03 87 c0 00 20 1b dc c0 03 87 .. ....... .....
> backtrace:
> [<000000004cc2790f>] kvmppc_create_pte+0x838/0xd20 [kvm_hv]
> kvmppc_pmd_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:366
> (inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:590
> [<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
> [<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
> [<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
> [<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
> [<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
> [<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
> [<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
> [<0000000048155cd6>] ksys_ioctl+0xd8/0x130
> [<0000000041ffeaa7>] sys_ioctl+0x28/0x40
> [<000000004afc4310>] system_call_exception+0x114/0x1e0
> [<00000000fb70a873>] system_call_common+0xf0/0x278
> unreferenced object 0xc0002001f0c03900 (size 256):
> comm "qemu-kvm", pid 124830, jiffies 4295735235 (age 326.570s)
> hex dump (first 32 bytes):
> c0 00 20 10 fa a0 03 87 c0 00 20 10 fa a1 03 87 .. ....... .....
> c0 00 20 10 fa a2 03 87 c0 00 20 10 fa a3 03 87 .. ....... .....
> backtrace:
> [<0000000023f675b8>] kvmppc_create_pte+0x854/0xd20 [kvm_hv]
> kvmppc_pte_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:356
> (inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:593
> [<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
> [<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
> [<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
> [<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
> [<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
> [<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
> [<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
> [<0000000048155cd6>] ksys_ioctl+0xd8/0x130
> [<0000000041ffeaa7>] sys_ioctl+0x28/0x40
> [<000000004afc4310>] system_call_exception+0x114/0x1e0
> [<00000000fb70a873>] system_call_common+0xf0/0x278
> unreferenced object 0xc000201b53e90000 (size 65536):
> comm "qemu-kvm", pid 124557, jiffies 4295650285 (age 364.370s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<00000000acc2fb77>] xive_native_alloc_vp_block+0x168/0x210
> xive_native_provision_pages at arch/powerpc/sysdev/xive/native.c:645
> (inlined by) xive_native_alloc_vp_block at arch/powerpc/sysdev/xive/native.c:674
> [<000000004d5c7964>] kvmppc_xive_compute_vp_id+0x20c/0x3b0 [kvm]
> [<0000000055317cd2>] kvmppc_xive_connect_vcpu+0xa4/0x4a0 [kvm]
> [<0000000093dfc014>] kvm_arch_vcpu_ioctl+0x388/0x508 [kvm]
> [<00000000d25aea0f>] kvm_vcpu_ioctl+0x15c/0x950 [kvm]
> [<0000000048155cd6>] ksys_ioctl+0xd8/0x130
> [<0000000041ffeaa7>] sys_ioctl+0x28/0x40
> [<000000004afc4310>] system_call_exception+0x114/0x1e0
> [<00000000fb70a873>] system_call_common+0xf0/0x278
>
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
> arch/powerpc/kvm/book3s_64_mmu_radix.c | 16 ++++++++++++++--
> arch/powerpc/sysdev/xive/native.c | 4 ++++
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c
> index aa12cd4078b3..bc6c1aa3d0e9 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
> @@ -353,7 +353,13 @@ static struct kmem_cache *kvm_pmd_cache;
>
> static pte_t *kvmppc_pte_alloc(void)
> {
> - return kmem_cache_alloc(kvm_pte_cache, GFP_KERNEL);
> + pte_t *pte;
> +
> + pte = kmem_cache_alloc(kvm_pte_cache, GFP_KERNEL);
> + /* pmd_populate() will only reference _pa(pte). */
> + kmemleak_ignore(pte);
> +
> + return pte;
> }
>
> static void kvmppc_pte_free(pte_t *ptep)
> @@ -363,7 +369,13 @@ static void kvmppc_pte_free(pte_t *ptep)
>
> static pmd_t *kvmppc_pmd_alloc(void)
> {
> - return kmem_cache_alloc(kvm_pmd_cache, GFP_KERNEL);
> + pmd_t *pmd;
> +
> + pmd = kmem_cache_alloc(kvm_pmd_cache, GFP_KERNEL);
> + /* pud_populate() will only reference _pa(pmd). */
> + kmemleak_ignore(pmd);
> +
> + return pmd;
> }
>
> static void kvmppc_pmd_free(pmd_t *pmdp)
> diff --git a/arch/powerpc/sysdev/xive/native.c b/arch/powerpc/sysdev/xive/native.c
> index 5218fdc4b29a..2d19f28967a6 100644
> --- a/arch/powerpc/sysdev/xive/native.c
> +++ b/arch/powerpc/sysdev/xive/native.c
> @@ -18,6 +18,7 @@
> #include <linux/delay.h>
> #include <linux/cpumask.h>
> #include <linux/mm.h>
> +#include <linux/kmemleak.h>
>
> #include <asm/machdep.h>
> #include <asm/prom.h>
> @@ -647,6 +648,9 @@ static bool xive_native_provision_pages(void)
> pr_err("Failed to allocate provisioning page\n");
> return false;
> }
> + /* Kmemleak is unable to track the physical address. */
> + kmemleak_ignore(p);
> +
> opal_xive_donate_page(chip, __pa(p));
> }
> return true;
> --
> 2.21.0 (Apple Git-122.2)
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
@ 2020-05-11 11:15 ` Michael Ellerman
0 siblings, 0 replies; 24+ messages in thread
From: Michael Ellerman @ 2020-05-11 11:15 UTC (permalink / raw)
To: Qian Cai; +Cc: linux-kernel, kvm-ppc, Qian Cai, catalin.marinas, linuxppc-dev
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.
Did you try that?
cheers
> unreferenced object 0xc000201c382a1000 (size 4096):
> comm "qemu-kvm", pid 124828, jiffies 4295733767 (age 341.250s)
> hex dump (first 32 bytes):
> c0 00 20 09 f4 60 03 87 c0 00 20 10 72 a0 03 87 .. ..`.... .r...
> c0 00 20 0e 13 a0 03 87 c0 00 20 1b dc c0 03 87 .. ....... .....
> backtrace:
> [<000000004cc2790f>] kvmppc_create_pte+0x838/0xd20 [kvm_hv]
> kvmppc_pmd_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:366
> (inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:590
> [<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
> [<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
> [<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
> [<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
> [<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
> [<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
> [<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
> [<0000000048155cd6>] ksys_ioctl+0xd8/0x130
> [<0000000041ffeaa7>] sys_ioctl+0x28/0x40
> [<000000004afc4310>] system_call_exception+0x114/0x1e0
> [<00000000fb70a873>] system_call_common+0xf0/0x278
> unreferenced object 0xc0002001f0c03900 (size 256):
> comm "qemu-kvm", pid 124830, jiffies 4295735235 (age 326.570s)
> hex dump (first 32 bytes):
> c0 00 20 10 fa a0 03 87 c0 00 20 10 fa a1 03 87 .. ....... .....
> c0 00 20 10 fa a2 03 87 c0 00 20 10 fa a3 03 87 .. ....... .....
> backtrace:
> [<0000000023f675b8>] kvmppc_create_pte+0x854/0xd20 [kvm_hv]
> kvmppc_pte_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:356
> (inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:593
> [<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
> [<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
> [<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
> [<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
> [<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
> [<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
> [<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
> [<0000000048155cd6>] ksys_ioctl+0xd8/0x130
> [<0000000041ffeaa7>] sys_ioctl+0x28/0x40
> [<000000004afc4310>] system_call_exception+0x114/0x1e0
> [<00000000fb70a873>] system_call_common+0xf0/0x278
> unreferenced object 0xc000201b53e90000 (size 65536):
> comm "qemu-kvm", pid 124557, jiffies 4295650285 (age 364.370s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<00000000acc2fb77>] xive_native_alloc_vp_block+0x168/0x210
> xive_native_provision_pages at arch/powerpc/sysdev/xive/native.c:645
> (inlined by) xive_native_alloc_vp_block at arch/powerpc/sysdev/xive/native.c:674
> [<000000004d5c7964>] kvmppc_xive_compute_vp_id+0x20c/0x3b0 [kvm]
> [<0000000055317cd2>] kvmppc_xive_connect_vcpu+0xa4/0x4a0 [kvm]
> [<0000000093dfc014>] kvm_arch_vcpu_ioctl+0x388/0x508 [kvm]
> [<00000000d25aea0f>] kvm_vcpu_ioctl+0x15c/0x950 [kvm]
> [<0000000048155cd6>] ksys_ioctl+0xd8/0x130
> [<0000000041ffeaa7>] sys_ioctl+0x28/0x40
> [<000000004afc4310>] system_call_exception+0x114/0x1e0
> [<00000000fb70a873>] system_call_common+0xf0/0x278
>
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
> arch/powerpc/kvm/book3s_64_mmu_radix.c | 16 ++++++++++++++--
> arch/powerpc/sysdev/xive/native.c | 4 ++++
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c
> index aa12cd4078b3..bc6c1aa3d0e9 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
> @@ -353,7 +353,13 @@ static struct kmem_cache *kvm_pmd_cache;
>
> static pte_t *kvmppc_pte_alloc(void)
> {
> - return kmem_cache_alloc(kvm_pte_cache, GFP_KERNEL);
> + pte_t *pte;
> +
> + pte = kmem_cache_alloc(kvm_pte_cache, GFP_KERNEL);
> + /* pmd_populate() will only reference _pa(pte). */
> + kmemleak_ignore(pte);
> +
> + return pte;
> }
>
> static void kvmppc_pte_free(pte_t *ptep)
> @@ -363,7 +369,13 @@ static void kvmppc_pte_free(pte_t *ptep)
>
> static pmd_t *kvmppc_pmd_alloc(void)
> {
> - return kmem_cache_alloc(kvm_pmd_cache, GFP_KERNEL);
> + pmd_t *pmd;
> +
> + pmd = kmem_cache_alloc(kvm_pmd_cache, GFP_KERNEL);
> + /* pud_populate() will only reference _pa(pmd). */
> + kmemleak_ignore(pmd);
> +
> + return pmd;
> }
>
> static void kvmppc_pmd_free(pmd_t *pmdp)
> diff --git a/arch/powerpc/sysdev/xive/native.c b/arch/powerpc/sysdev/xive/native.c
> index 5218fdc4b29a..2d19f28967a6 100644
> --- a/arch/powerpc/sysdev/xive/native.c
> +++ b/arch/powerpc/sysdev/xive/native.c
> @@ -18,6 +18,7 @@
> #include <linux/delay.h>
> #include <linux/cpumask.h>
> #include <linux/mm.h>
> +#include <linux/kmemleak.h>
>
> #include <asm/machdep.h>
> #include <asm/prom.h>
> @@ -647,6 +648,9 @@ static bool xive_native_provision_pages(void)
> pr_err("Failed to allocate provisioning page\n");
> return false;
> }
> + /* Kmemleak is unable to track the physical address. */
> + kmemleak_ignore(p);
> +
> opal_xive_donate_page(chip, __pa(p));
> }
> return true;
> --
> 2.21.0 (Apple Git-122.2)
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
2020-05-11 11:15 ` Michael Ellerman
(?)
@ 2020-05-11 11:28 ` Catalin Marinas
-1 siblings, 0 replies; 24+ messages in thread
From: Catalin Marinas @ 2020-05-11 11:28 UTC (permalink / raw)
To: Michael Ellerman
Cc: Qian Cai, paulus, benh, kvm-ppc, linuxppc-dev, linux-kernel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
@ 2020-05-11 11:28 ` Catalin Marinas
0 siblings, 0 replies; 24+ messages in thread
From: Catalin Marinas @ 2020-05-11 11:28 UTC (permalink / raw)
To: Michael Ellerman
Cc: Qian Cai, paulus, benh, kvm-ppc, linuxppc-dev, linux-kernel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
@ 2020-05-11 11:28 ` Catalin Marinas
0 siblings, 0 replies; 24+ messages in thread
From: Catalin Marinas @ 2020-05-11 11:28 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linux-kernel, kvm-ppc, Qian Cai, linuxppc-dev
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
2020-05-11 11:28 ` Catalin Marinas
(?)
@ 2020-05-13 4:00 ` Michael Ellerman
-1 siblings, 0 replies; 24+ messages in thread
From: Michael Ellerman @ 2020-05-13 4:00 UTC (permalink / raw)
To: Catalin Marinas
Cc: Qian Cai, paulus, benh, kvm-ppc, linuxppc-dev, linux-kernel
Catalin Marinas <catalin.marinas@arm.com> writes:
> 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.
OK, thanks for clarifying that.
> 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.
Agreed.
cheers
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
@ 2020-05-13 4:00 ` Michael Ellerman
0 siblings, 0 replies; 24+ messages in thread
From: Michael Ellerman @ 2020-05-13 4:00 UTC (permalink / raw)
To: Catalin Marinas
Cc: Qian Cai, paulus, benh, kvm-ppc, linuxppc-dev, linux-kernel
Catalin Marinas <catalin.marinas@arm.com> writes:
> 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.
OK, thanks for clarifying that.
> 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.
Agreed.
cheers
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
@ 2020-05-13 4:00 ` Michael Ellerman
0 siblings, 0 replies; 24+ messages in thread
From: Michael Ellerman @ 2020-05-13 4:00 UTC (permalink / raw)
To: Catalin Marinas; +Cc: linux-kernel, kvm-ppc, Qian Cai, linuxppc-dev
Catalin Marinas <catalin.marinas@arm.com> writes:
> 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.
OK, thanks for clarifying that.
> 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.
Agreed.
cheers
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
2020-05-11 11:15 ` Michael Ellerman
(?)
@ 2020-05-11 11:43 ` Qian Cai
-1 siblings, 0 replies; 24+ messages in thread
From: Qian Cai @ 2020-05-11 11:43 UTC (permalink / raw)
To: Michael Ellerman
Cc: paulus, benh, catalin.marinas, kvm-ppc, linuxppc-dev, linux-kernel
> On May 11, 2020, at 7:15 AM, Michael Ellerman <mpe@ellerman.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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
@ 2020-05-11 11:43 ` Qian Cai
0 siblings, 0 replies; 24+ messages in thread
From: Qian Cai @ 2020-05-11 11:43 UTC (permalink / raw)
To: Michael Ellerman
Cc: paulus, benh, catalin.marinas, kvm-ppc, linuxppc-dev, linux-kernel
> On May 11, 2020, at 7:15 AM, Michael Ellerman <mpe@ellerman.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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
@ 2020-05-11 11:43 ` Qian Cai
0 siblings, 0 replies; 24+ messages in thread
From: Qian Cai @ 2020-05-11 11:43 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linux-kernel, kvm-ppc, catalin.marinas, linuxppc-dev
> On May 11, 2020, at 7:15 AM, Michael Ellerman <mpe@ellerman.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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
2020-05-11 11:43 ` Qian Cai
(?)
@ 2020-05-12 14:17 ` Catalin Marinas
-1 siblings, 0 replies; 24+ messages in thread
From: Catalin Marinas @ 2020-05-12 14:17 UTC (permalink / raw)
To: Qian Cai
Cc: Michael Ellerman, paulus, benh, kvm-ppc, linuxppc-dev, linux-kernel
On Mon, May 11, 2020 at 07:43:30AM -0400, Qian Cai wrote:
> On May 11, 2020, at 7:15 AM, Michael Ellerman <mpe@ellerman.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?
>
> Catalin, 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.
Indeed. I replied directly to Michael along the same lines.
--
Catalin
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
@ 2020-05-12 14:17 ` Catalin Marinas
0 siblings, 0 replies; 24+ messages in thread
From: Catalin Marinas @ 2020-05-12 14:17 UTC (permalink / raw)
To: Qian Cai
Cc: Michael Ellerman, paulus, benh, kvm-ppc, linuxppc-dev, linux-kernel
On Mon, May 11, 2020 at 07:43:30AM -0400, Qian Cai wrote:
> On May 11, 2020, at 7:15 AM, Michael Ellerman <mpe@ellerman.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?
>
> Catalin, 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.
Indeed. I replied directly to Michael along the same lines.
--
Catalin
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
@ 2020-05-12 14:17 ` Catalin Marinas
0 siblings, 0 replies; 24+ messages in thread
From: Catalin Marinas @ 2020-05-12 14:17 UTC (permalink / raw)
To: Qian Cai; +Cc: linux-kernel, kvm-ppc, linuxppc-dev
On Mon, May 11, 2020 at 07:43:30AM -0400, Qian Cai wrote:
> On May 11, 2020, at 7:15 AM, Michael Ellerman <mpe@ellerman.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?
>
> Catalin, 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.
Indeed. I replied directly to Michael along the same lines.
--
Catalin
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
2020-05-09 1:55 ` Qian Cai
(?)
@ 2020-05-13 4:05 ` Michael Ellerman
-1 siblings, 0 replies; 24+ messages in thread
From: Michael Ellerman @ 2020-05-13 4:05 UTC (permalink / raw)
To: Qian Cai
Cc: paulus, benh, catalin.marinas, kvm-ppc, linuxppc-dev,
linux-kernel, Qian Cai
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().
Can you please split this into two patches, one for the KVM cases and
one for xive.
That way the KVM patch can go via the kvm-ppc tree, and I'll take the
xive one via powerpc.
> Since kmemleak is unable to track the physical memory resulting in false
> positives, silence those by using kmemleak_ignore().
>
> unreferenced object 0xc000201c382a1000 (size 4096):
> comm "qemu-kvm", pid 124828, jiffies 4295733767 (age 341.250s)
> hex dump (first 32 bytes):
> c0 00 20 09 f4 60 03 87 c0 00 20 10 72 a0 03 87 .. ..`.... .r...
> c0 00 20 0e 13 a0 03 87 c0 00 20 1b dc c0 03 87 .. ....... .....
> backtrace:
> [<000000004cc2790f>] kvmppc_create_pte+0x838/0xd20 [kvm_hv]
> kvmppc_pmd_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:366
> (inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:590
> [<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
> [<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
> [<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
> [<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
> [<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
> [<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
> [<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
> [<0000000048155cd6>] ksys_ioctl+0xd8/0x130
> [<0000000041ffeaa7>] sys_ioctl+0x28/0x40
> [<000000004afc4310>] system_call_exception+0x114/0x1e0
> [<00000000fb70a873>] system_call_common+0xf0/0x278
> unreferenced object 0xc0002001f0c03900 (size 256):
> comm "qemu-kvm", pid 124830, jiffies 4295735235 (age 326.570s)
> hex dump (first 32 bytes):
> c0 00 20 10 fa a0 03 87 c0 00 20 10 fa a1 03 87 .. ....... .....
> c0 00 20 10 fa a2 03 87 c0 00 20 10 fa a3 03 87 .. ....... .....
> backtrace:
> [<0000000023f675b8>] kvmppc_create_pte+0x854/0xd20 [kvm_hv]
> kvmppc_pte_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:356
> (inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:593
> [<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
> [<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
> [<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
> [<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
> [<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
> [<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
> [<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
> [<0000000048155cd6>] ksys_ioctl+0xd8/0x130
> [<0000000041ffeaa7>] sys_ioctl+0x28/0x40
> [<000000004afc4310>] system_call_exception+0x114/0x1e0
> [<00000000fb70a873>] system_call_common+0xf0/0x278
> unreferenced object 0xc000201b53e90000 (size 65536):
> comm "qemu-kvm", pid 124557, jiffies 4295650285 (age 364.370s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<00000000acc2fb77>] xive_native_alloc_vp_block+0x168/0x210
> xive_native_provision_pages at arch/powerpc/sysdev/xive/native.c:645
> (inlined by) xive_native_alloc_vp_block at arch/powerpc/sysdev/xive/native.c:674
> [<000000004d5c7964>] kvmppc_xive_compute_vp_id+0x20c/0x3b0 [kvm]
> [<0000000055317cd2>] kvmppc_xive_connect_vcpu+0xa4/0x4a0 [kvm]
> [<0000000093dfc014>] kvm_arch_vcpu_ioctl+0x388/0x508 [kvm]
> [<00000000d25aea0f>] kvm_vcpu_ioctl+0x15c/0x950 [kvm]
> [<0000000048155cd6>] ksys_ioctl+0xd8/0x130
> [<0000000041ffeaa7>] sys_ioctl+0x28/0x40
> [<000000004afc4310>] system_call_exception+0x114/0x1e0
> [<00000000fb70a873>] system_call_common+0xf0/0x278
>
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
> arch/powerpc/kvm/book3s_64_mmu_radix.c | 16 ++++++++++++++--
> arch/powerpc/sysdev/xive/native.c | 4 ++++
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c
> index aa12cd4078b3..bc6c1aa3d0e9 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
> @@ -353,7 +353,13 @@ static struct kmem_cache *kvm_pmd_cache;
This should probably also have an include of <linux/kmemleak.h> ?
> static pte_t *kvmppc_pte_alloc(void)
> {
> - return kmem_cache_alloc(kvm_pte_cache, GFP_KERNEL);
> + pte_t *pte;
> +
> + pte = kmem_cache_alloc(kvm_pte_cache, GFP_KERNEL);
> + /* pmd_populate() will only reference _pa(pte). */
> + kmemleak_ignore(pte);
> +
> + return pte;
> }
>
> static void kvmppc_pte_free(pte_t *ptep)
cheers
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
@ 2020-05-13 4:05 ` Michael Ellerman
0 siblings, 0 replies; 24+ messages in thread
From: Michael Ellerman @ 2020-05-13 4:05 UTC (permalink / raw)
To: Qian Cai
Cc: paulus, benh, catalin.marinas, kvm-ppc, linuxppc-dev,
linux-kernel, Qian Cai
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().
Can you please split this into two patches, one for the KVM cases and
one for xive.
That way the KVM patch can go via the kvm-ppc tree, and I'll take the
xive one via powerpc.
> Since kmemleak is unable to track the physical memory resulting in false
> positives, silence those by using kmemleak_ignore().
>
> unreferenced object 0xc000201c382a1000 (size 4096):
> comm "qemu-kvm", pid 124828, jiffies 4295733767 (age 341.250s)
> hex dump (first 32 bytes):
> c0 00 20 09 f4 60 03 87 c0 00 20 10 72 a0 03 87 .. ..`.... .r...
> c0 00 20 0e 13 a0 03 87 c0 00 20 1b dc c0 03 87 .. ....... .....
> backtrace:
> [<000000004cc2790f>] kvmppc_create_pte+0x838/0xd20 [kvm_hv]
> kvmppc_pmd_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:366
> (inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:590
> [<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
> [<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
> [<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
> [<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
> [<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
> [<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
> [<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
> [<0000000048155cd6>] ksys_ioctl+0xd8/0x130
> [<0000000041ffeaa7>] sys_ioctl+0x28/0x40
> [<000000004afc4310>] system_call_exception+0x114/0x1e0
> [<00000000fb70a873>] system_call_common+0xf0/0x278
> unreferenced object 0xc0002001f0c03900 (size 256):
> comm "qemu-kvm", pid 124830, jiffies 4295735235 (age 326.570s)
> hex dump (first 32 bytes):
> c0 00 20 10 fa a0 03 87 c0 00 20 10 fa a1 03 87 .. ....... .....
> c0 00 20 10 fa a2 03 87 c0 00 20 10 fa a3 03 87 .. ....... .....
> backtrace:
> [<0000000023f675b8>] kvmppc_create_pte+0x854/0xd20 [kvm_hv]
> kvmppc_pte_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:356
> (inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:593
> [<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
> [<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
> [<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
> [<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
> [<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
> [<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
> [<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
> [<0000000048155cd6>] ksys_ioctl+0xd8/0x130
> [<0000000041ffeaa7>] sys_ioctl+0x28/0x40
> [<000000004afc4310>] system_call_exception+0x114/0x1e0
> [<00000000fb70a873>] system_call_common+0xf0/0x278
> unreferenced object 0xc000201b53e90000 (size 65536):
> comm "qemu-kvm", pid 124557, jiffies 4295650285 (age 364.370s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<00000000acc2fb77>] xive_native_alloc_vp_block+0x168/0x210
> xive_native_provision_pages at arch/powerpc/sysdev/xive/native.c:645
> (inlined by) xive_native_alloc_vp_block at arch/powerpc/sysdev/xive/native.c:674
> [<000000004d5c7964>] kvmppc_xive_compute_vp_id+0x20c/0x3b0 [kvm]
> [<0000000055317cd2>] kvmppc_xive_connect_vcpu+0xa4/0x4a0 [kvm]
> [<0000000093dfc014>] kvm_arch_vcpu_ioctl+0x388/0x508 [kvm]
> [<00000000d25aea0f>] kvm_vcpu_ioctl+0x15c/0x950 [kvm]
> [<0000000048155cd6>] ksys_ioctl+0xd8/0x130
> [<0000000041ffeaa7>] sys_ioctl+0x28/0x40
> [<000000004afc4310>] system_call_exception+0x114/0x1e0
> [<00000000fb70a873>] system_call_common+0xf0/0x278
>
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
> arch/powerpc/kvm/book3s_64_mmu_radix.c | 16 ++++++++++++++--
> arch/powerpc/sysdev/xive/native.c | 4 ++++
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c
> index aa12cd4078b3..bc6c1aa3d0e9 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
> @@ -353,7 +353,13 @@ static struct kmem_cache *kvm_pmd_cache;
This should probably also have an include of <linux/kmemleak.h> ?
> static pte_t *kvmppc_pte_alloc(void)
> {
> - return kmem_cache_alloc(kvm_pte_cache, GFP_KERNEL);
> + pte_t *pte;
> +
> + pte = kmem_cache_alloc(kvm_pte_cache, GFP_KERNEL);
> + /* pmd_populate() will only reference _pa(pte). */
> + kmemleak_ignore(pte);
> +
> + return pte;
> }
>
> static void kvmppc_pte_free(pte_t *ptep)
cheers
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
@ 2020-05-13 4:05 ` Michael Ellerman
0 siblings, 0 replies; 24+ messages in thread
From: Michael Ellerman @ 2020-05-13 4:05 UTC (permalink / raw)
To: Qian Cai; +Cc: linux-kernel, kvm-ppc, Qian Cai, catalin.marinas, linuxppc-dev
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().
Can you please split this into two patches, one for the KVM cases and
one for xive.
That way the KVM patch can go via the kvm-ppc tree, and I'll take the
xive one via powerpc.
> Since kmemleak is unable to track the physical memory resulting in false
> positives, silence those by using kmemleak_ignore().
>
> unreferenced object 0xc000201c382a1000 (size 4096):
> comm "qemu-kvm", pid 124828, jiffies 4295733767 (age 341.250s)
> hex dump (first 32 bytes):
> c0 00 20 09 f4 60 03 87 c0 00 20 10 72 a0 03 87 .. ..`.... .r...
> c0 00 20 0e 13 a0 03 87 c0 00 20 1b dc c0 03 87 .. ....... .....
> backtrace:
> [<000000004cc2790f>] kvmppc_create_pte+0x838/0xd20 [kvm_hv]
> kvmppc_pmd_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:366
> (inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:590
> [<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
> [<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
> [<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
> [<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
> [<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
> [<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
> [<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
> [<0000000048155cd6>] ksys_ioctl+0xd8/0x130
> [<0000000041ffeaa7>] sys_ioctl+0x28/0x40
> [<000000004afc4310>] system_call_exception+0x114/0x1e0
> [<00000000fb70a873>] system_call_common+0xf0/0x278
> unreferenced object 0xc0002001f0c03900 (size 256):
> comm "qemu-kvm", pid 124830, jiffies 4295735235 (age 326.570s)
> hex dump (first 32 bytes):
> c0 00 20 10 fa a0 03 87 c0 00 20 10 fa a1 03 87 .. ....... .....
> c0 00 20 10 fa a2 03 87 c0 00 20 10 fa a3 03 87 .. ....... .....
> backtrace:
> [<0000000023f675b8>] kvmppc_create_pte+0x854/0xd20 [kvm_hv]
> kvmppc_pte_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:356
> (inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:593
> [<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
> [<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
> [<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
> [<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
> [<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
> [<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
> [<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
> [<0000000048155cd6>] ksys_ioctl+0xd8/0x130
> [<0000000041ffeaa7>] sys_ioctl+0x28/0x40
> [<000000004afc4310>] system_call_exception+0x114/0x1e0
> [<00000000fb70a873>] system_call_common+0xf0/0x278
> unreferenced object 0xc000201b53e90000 (size 65536):
> comm "qemu-kvm", pid 124557, jiffies 4295650285 (age 364.370s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<00000000acc2fb77>] xive_native_alloc_vp_block+0x168/0x210
> xive_native_provision_pages at arch/powerpc/sysdev/xive/native.c:645
> (inlined by) xive_native_alloc_vp_block at arch/powerpc/sysdev/xive/native.c:674
> [<000000004d5c7964>] kvmppc_xive_compute_vp_id+0x20c/0x3b0 [kvm]
> [<0000000055317cd2>] kvmppc_xive_connect_vcpu+0xa4/0x4a0 [kvm]
> [<0000000093dfc014>] kvm_arch_vcpu_ioctl+0x388/0x508 [kvm]
> [<00000000d25aea0f>] kvm_vcpu_ioctl+0x15c/0x950 [kvm]
> [<0000000048155cd6>] ksys_ioctl+0xd8/0x130
> [<0000000041ffeaa7>] sys_ioctl+0x28/0x40
> [<000000004afc4310>] system_call_exception+0x114/0x1e0
> [<00000000fb70a873>] system_call_common+0xf0/0x278
>
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
> arch/powerpc/kvm/book3s_64_mmu_radix.c | 16 ++++++++++++++--
> arch/powerpc/sysdev/xive/native.c | 4 ++++
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c
> index aa12cd4078b3..bc6c1aa3d0e9 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
> @@ -353,7 +353,13 @@ static struct kmem_cache *kvm_pmd_cache;
This should probably also have an include of <linux/kmemleak.h> ?
> static pte_t *kvmppc_pte_alloc(void)
> {
> - return kmem_cache_alloc(kvm_pte_cache, GFP_KERNEL);
> + pte_t *pte;
> +
> + pte = kmem_cache_alloc(kvm_pte_cache, GFP_KERNEL);
> + /* pmd_populate() will only reference _pa(pte). */
> + kmemleak_ignore(pte);
> +
> + return pte;
> }
>
> static void kvmppc_pte_free(pte_t *ptep)
cheers
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
2020-05-13 4:05 ` Michael Ellerman
(?)
@ 2020-05-13 6:24 ` Qian Cai
-1 siblings, 0 replies; 24+ messages in thread
From: Qian Cai @ 2020-05-13 6:24 UTC (permalink / raw)
To: Michael Ellerman
Cc: paulus, benh, catalin.marinas, kvm-ppc, linuxppc-dev, linux-kernel
> On May 13, 2020, at 12:04 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> This should probably also have an include of <linux/kmemleak.h> ?
No, asm/book3s/64/pgalloc.h has already had it and since this is book3s_64_mmu_radix.c, it will include it eventually from,
asm/pgalloc.h
asm/book3s/pgalloc.h
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
@ 2020-05-13 6:24 ` Qian Cai
0 siblings, 0 replies; 24+ messages in thread
From: Qian Cai @ 2020-05-13 6:24 UTC (permalink / raw)
To: Michael Ellerman
Cc: paulus, benh, catalin.marinas, kvm-ppc, linuxppc-dev, linux-kernel
> On May 13, 2020, at 12:04 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> This should probably also have an include of <linux/kmemleak.h> ?
No, asm/book3s/64/pgalloc.h has already had it and since this is book3s_64_mmu_radix.c, it will include it eventually from,
asm/pgalloc.h
asm/book3s/pgalloc.h
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] powerpc/kvm: silence kmemleak false positives
@ 2020-05-13 6:24 ` Qian Cai
0 siblings, 0 replies; 24+ messages in thread
From: Qian Cai @ 2020-05-13 6:24 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linux-kernel, kvm-ppc, catalin.marinas, linuxppc-dev
> On May 13, 2020, at 12:04 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> This should probably also have an include of <linux/kmemleak.h> ?
No, asm/book3s/64/pgalloc.h has already had it and since this is book3s_64_mmu_radix.c, it will include it eventually from,
asm/pgalloc.h
asm/book3s/pgalloc.h
^ permalink raw reply [flat|nested] 24+ messages in thread