On Fri, 2022-05-27 at 21:39 +0800, patrick wang wrote:
> On Fri, May 27, 2022 at 11:25 AM <yee.lee@xxxxxxxxxxxx> wrote:
> >
> > From: Yee Lee <yee.lee@xxxxxxxxxxxx>
> >
> > 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 <yee.lee@xxxxxxxxxxxx>
> > ---
> > 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.
> > 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
> >
