* [PATCH] mm: percpu: use kmemleak_ignore_phys() instead of kmemleak_free()
@ 2022-07-05 11:31 Patrick Wang
2022-07-05 21:20 ` Andrew Morton
0 siblings, 1 reply; 4+ messages in thread
From: Patrick Wang @ 2022-07-05 11:31 UTC (permalink / raw)
To: dennis, tj, cl, akpm
Cc: catalin.marinas, linux-mm, linux-kernel, patrick.wang.shcn
Kmemleak recently added a rbtree to store the objects
allocted with physical address. Those objects can't be
freed with kmemleak_free(). Use kmemleak_ignore_phys()
instead of kmemleak_free() for those objects.
Signed-off-by: Patrick Wang <patrick.wang.shcn@gmail.com>
---
Similar to:
https://lkml.kernel.org/r/20220628113714.7792-2-yee.lee@mediatek.com
mm/percpu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/percpu.c b/mm/percpu.c
index 3633eeefaa0d..27697b2429c2 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -3104,7 +3104,7 @@ int __init pcpu_embed_first_chunk(size_t reserved_size, size_t dyn_size,
goto out_free_areas;
}
/* kmemleak tracks the percpu allocations separately */
- kmemleak_free(ptr);
+ kmemleak_ignore_phys(__pa(ptr));
areas[group] = ptr;
base = min(ptr, base);
@@ -3304,7 +3304,7 @@ int __init pcpu_page_first_chunk(size_t reserved_size, pcpu_fc_cpu_to_node_fn_t
goto enomem;
}
/* kmemleak tracks the percpu allocations separately */
- kmemleak_free(ptr);
+ kmemleak_ignore_phys(__pa(ptr));
pages[j++] = virt_to_page(ptr);
}
}
@@ -3417,7 +3417,7 @@ void __init setup_per_cpu_areas(void)
if (!ai || !fc)
panic("Failed to allocate memory for percpu areas.");
/* kmemleak tracks the percpu allocations separately */
- kmemleak_free(fc);
+ kmemleak_ignore_phys(__pa(fc));
ai->dyn_size = unit_size;
ai->unit_size = unit_size;
--
2.25.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] mm: percpu: use kmemleak_ignore_phys() instead of kmemleak_free()
2022-07-05 11:31 [PATCH] mm: percpu: use kmemleak_ignore_phys() instead of kmemleak_free() Patrick Wang
@ 2022-07-05 21:20 ` Andrew Morton
2022-07-06 14:44 ` patrick wang
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Morton @ 2022-07-05 21:20 UTC (permalink / raw)
To: Patrick Wang; +Cc: dennis, tj, cl, catalin.marinas, linux-mm, linux-kernel
On Tue, 5 Jul 2022 19:31:58 +0800 Patrick Wang <patrick.wang.shcn@gmail.com> wrote:
> Kmemleak recently added a rbtree to store the objects
> allocted with physical address. Those objects can't be
> freed with kmemleak_free(). Use kmemleak_ignore_phys()
> instead of kmemleak_free() for those objects.
Thanks. What are the user-visible runtime effects of this?
And are we able to identify a commit for the Fixes: line?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] mm: percpu: use kmemleak_ignore_phys() instead of kmemleak_free()
2022-07-05 21:20 ` Andrew Morton
@ 2022-07-06 14:44 ` patrick wang
2022-07-12 10:59 ` Catalin Marinas
0 siblings, 1 reply; 4+ messages in thread
From: patrick wang @ 2022-07-06 14:44 UTC (permalink / raw)
To: Andrew Morton
Cc: dennis, tj, cl, Catalin Marinas, open list:MEMORY MANAGEMENT,
linux-kernel
On Wed, Jul 6, 2022 at 5:20 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Tue, 5 Jul 2022 19:31:58 +0800 Patrick Wang <patrick.wang.shcn@gmail.com> wrote:
>
> > Kmemleak recently added a rbtree to store the objects
> > allocted with physical address. Those objects can't be
> > freed with kmemleak_free(). Use kmemleak_ignore_phys()
> > instead of kmemleak_free() for those objects.
>
> Thanks. What are the user-visible runtime effects of this?
According to the comments, percpu allocations are tracked
by kmemleak separately. Kmemleak_free() was used to avoid
the unnecessary tracking. If kmemleak_free() fails, those
objects would be scanned by kmemleak, which is unnecessary
but shouldn't lead to other effects.
I didn't observe any anomaly without this commit on riscv
and arm64.
>
> And are we able to identify a commit for the Fixes: line?
0c24e061196c (mm: kmemleak: add rbtree and store physical
address for objects allocated with PA)
Current in mm-stable.
Thanks,
Patrick
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] mm: percpu: use kmemleak_ignore_phys() instead of kmemleak_free()
2022-07-06 14:44 ` patrick wang
@ 2022-07-12 10:59 ` Catalin Marinas
0 siblings, 0 replies; 4+ messages in thread
From: Catalin Marinas @ 2022-07-12 10:59 UTC (permalink / raw)
To: patrick wang
Cc: Andrew Morton, dennis, tj, cl, open list:MEMORY MANAGEMENT, linux-kernel
On Wed, Jul 06, 2022 at 10:44:11PM +0800, patrick wang wrote:
> On Wed, Jul 6, 2022 at 5:20 AM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Tue, 5 Jul 2022 19:31:58 +0800 Patrick Wang <patrick.wang.shcn@gmail.com> wrote:
> >
> > > Kmemleak recently added a rbtree to store the objects
> > > allocted with physical address. Those objects can't be
> > > freed with kmemleak_free(). Use kmemleak_ignore_phys()
> > > instead of kmemleak_free() for those objects.
> >
> > Thanks. What are the user-visible runtime effects of this?
>
> According to the comments, percpu allocations are tracked
> by kmemleak separately. Kmemleak_free() was used to avoid
> the unnecessary tracking. If kmemleak_free() fails, those
> objects would be scanned by kmemleak, which is unnecessary
> but shouldn't lead to other effects.
>
> I didn't observe any anomaly without this commit on riscv
> and arm64.
What could happen is an increased rate of false negatives as it scans
more than necessary.
> > And are we able to identify a commit for the Fixes: line?
>
> 0c24e061196c (mm: kmemleak: add rbtree and store physical
> address for objects allocated with PA)
> Current in mm-stable.
I think we could add a Fixes line for the above. For the patch:
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-07-12 11:00 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-05 11:31 [PATCH] mm: percpu: use kmemleak_ignore_phys() instead of kmemleak_free() Patrick Wang
2022-07-05 21:20 ` Andrew Morton
2022-07-06 14:44 ` patrick wang
2022-07-12 10:59 ` Catalin Marinas
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.