Re: [PATCH] mm: kmemleak: Skip check in kmemleak_*_phys when pfn bound is not ready

On Fri, 2022-05-27 at 21:39 +0800, patrick wang wrote:

On Fri, May 27, 2022 at 11:25 AM [off-list ref] wrote:

quoted

From: Yee Lee <redacted>

In some archs (arm64), memblock allocates memory in boot time when
the pfn boundary (max_pfn/min_pfn) is not ready. The lowmen checks
in
kmemleak_*_phys() drop those blocks and cause some false leak
alarms
on common kernel objects.

Kmemleak output: (Qemu/arm64)
unreferenced object 0xffff0000c0170a00 (size 128):
  comm "swapper/0", pid 1, jiffies 4294892404 (age 126.208s)
  hex dump (first 32 bytes):
    62 61 73 65 00 00 00 00 00 00 00 00 00 00 00
00  base............
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00  ................
  backtrace:
    [<(____ptrval____)>] __kmalloc_track_caller+0x1b0/0x2e4
    [<(____ptrval____)>] kstrdup_const+0x8c/0xc4
    [<(____ptrval____)>] kvasprintf_const+0xbc/0xec
    [<(____ptrval____)>] kobject_set_name_vargs+0x58/0xe4
    [<(____ptrval____)>] kobject_add+0x84/0x100
    [<(____ptrval____)>] __of_attach_node_sysfs+0x78/0xec
    [<(____ptrval____)>] of_core_init+0x68/0x104
    [<(____ptrval____)>] driver_init+0x28/0x48
    [<(____ptrval____)>] do_basic_setup+0x14/0x28
    [<(____ptrval____)>] kernel_init_freeable+0x110/0x178
    [<(____ptrval____)>] kernel_init+0x20/0x1a0
    [<(____ptrval____)>] ret_from_fork+0x10/0x20

This patch relaxs the boundary checking in kmemleak_*_phys api
if max_low_pfn is uninitialzed.

Fixes: 23c2d4 (mm: kmemleak: take a full lowmem check in
kmemleak_*_phy)
Signed-off-by: Yee Lee <redacted>
---
 mm/kmemleak.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index a182f5ddaf68..6b2af544aa0f 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c

@@ -1132,7 +1132,7 @@ EXPORT_SYMBOL(kmemleak_no_scan);
 void __ref kmemleak_alloc_phys(phys_addr_t phys, size_t size, int

min_count,
                               gfp_t gfp)
 {
-       if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) <
max_low_pfn)
+       if (!max_low_pfn || (PHYS_PFN(phys) >= min_low_pfn &&
PHYS_PFN(phys) < max_low_pfn))

Just skip checking will bring the crash possibility back. Seems it's
beyond
these interfaces' handle scope for this situation, since
"min_low_pfn" and
"max_low_pfn" are depending on arches.

Yes, for the cases beyond the pfn guard, users have to take care the
boundary by themselves. 

quoted

                kmemleak_alloc(__va(phys), size, min_count, gfp);
 }
 EXPORT_SYMBOL(kmemleak_alloc_phys);

@@ -1146,7 +1146,7 @@ EXPORT_SYMBOL(kmemleak_alloc_phys);
  */
 void __ref kmemleak_free_part_phys(phys_addr_t phys, size_t size)
 {
-       if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) <

max_low_pfn)
+       if (!max_low_pfn || (PHYS_PFN(phys) >= min_low_pfn &&
PHYS_PFN(phys) < max_low_pfn))
                kmemleak_free_part(__va(phys), size);
 }
 EXPORT_SYMBOL(kmemleak_free_part_phys);

@@ -1158,7 +1158,7 @@ EXPORT_SYMBOL(kmemleak_free_part_phys);
  */
 void __ref kmemleak_not_leak_phys(phys_addr_t phys)
 {
-       if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) <

max_low_pfn)
+       if (!max_low_pfn || (PHYS_PFN(phys) >= min_low_pfn &&
PHYS_PFN(phys) < max_low_pfn))
                kmemleak_not_leak(__va(phys));
 }
 EXPORT_SYMBOL(kmemleak_not_leak_phys);

@@ -1170,7 +1170,7 @@ EXPORT_SYMBOL(kmemleak_not_leak_phys);
  */
 void __ref kmemleak_ignore_phys(phys_addr_t phys)
 {
-       if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) <

max_low_pfn)
+       if (!max_low_pfn || (PHYS_PFN(phys) >= min_low_pfn &&
PHYS_PFN(phys) < max_low_pfn))
                kmemleak_ignore(__va(phys));
 }
 EXPORT_SYMBOL(kmemleak_ignore_phys);
--
2.18.0

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel