| Message ID | 20220705113158.127600-1-patrick.wang.shcn@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm: percpu: use kmemleak_ignore_phys() instead of kmemleak_free() | expand |
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?
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
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>
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;
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(-)