* [PATCH 0/1] mm: kfence: remove kfence_pool from leak trace
@ 2022-06-23 11:19 ` yee.lee
0 siblings, 0 replies; 13+ messages in thread
From: yee.lee @ 2022-06-23 11:19 UTC (permalink / raw)
To: linux-kernel
Cc: Yee Lee, Matthias Brugger,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
From: Yee Lee <yee.lee@mediatek.com>
Since the latest patches of kmemleak separated its address management
to two, phys and virt, rb-trees, the kmemleak_free failed to free kfence_pool
in the virt tree. It caused unexpected scan the blocks and triggered
kfence faults.
Reference:
https://lore.kernel.org/linux-mm/20220611035551.1823303-1-patrick.wang.shcn@gmail.com/
==================================================================
BUG: KFENCE: invalid read in scan_block+0x13c/0x838
Invalid read at 0x000000003dc26873:
scan_block+0x13c/0x838
scan_gray_list+0x1f0/0x478
kmemleak_scan+0x63c/0xd64
kmemleak_write+0x618/0x8cc
full_proxy_write+0x70/0x138
vfs_write+0x108/0x314
ksys_write+0x7c/0x14c
__arm64_sys_write+0x20/0x30
el0_svc_common+0xa8/0x144
do_el0_svc+0x30/0xd4
el0_svc+0x38/0x15c
el0t_64_sync_handler+0x88/0xf8
el0t_64_sync+0x1a0/0x1a4
CPU: 0 PID: 128 Comm: sh Not tainted 5.18.0-mainline-40996-g7d83a175ff4a-dirty #1
Hardware name: linux,dummy-virt (DT)
==================================================================
This patch change to call the memblock alloc with the flag to skip leak tracking.
And the latter kmemleak_free can be removed too.
Yee Lee (1):
mm: kfence: skip kmemleak alloc in kfence_pool
mm/kfence/core.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
--
2.18.0
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 0/1] mm: kfence: remove kfence_pool from leak trace
@ 2022-06-23 11:19 ` yee.lee
0 siblings, 0 replies; 13+ messages in thread
From: yee.lee @ 2022-06-23 11:19 UTC (permalink / raw)
To: linux-kernel
Cc: Yee Lee, Matthias Brugger,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
From: Yee Lee <yee.lee@mediatek.com>
Since the latest patches of kmemleak separated its address management
to two, phys and virt, rb-trees, the kmemleak_free failed to free kfence_pool
in the virt tree. It caused unexpected scan the blocks and triggered
kfence faults.
Reference:
https://lore.kernel.org/linux-mm/20220611035551.1823303-1-patrick.wang.shcn@gmail.com/
==================================================================
BUG: KFENCE: invalid read in scan_block+0x13c/0x838
Invalid read at 0x000000003dc26873:
scan_block+0x13c/0x838
scan_gray_list+0x1f0/0x478
kmemleak_scan+0x63c/0xd64
kmemleak_write+0x618/0x8cc
full_proxy_write+0x70/0x138
vfs_write+0x108/0x314
ksys_write+0x7c/0x14c
__arm64_sys_write+0x20/0x30
el0_svc_common+0xa8/0x144
do_el0_svc+0x30/0xd4
el0_svc+0x38/0x15c
el0t_64_sync_handler+0x88/0xf8
el0t_64_sync+0x1a0/0x1a4
CPU: 0 PID: 128 Comm: sh Not tainted 5.18.0-mainline-40996-g7d83a175ff4a-dirty #1
Hardware name: linux,dummy-virt (DT)
==================================================================
This patch change to call the memblock alloc with the flag to skip leak tracking.
And the latter kmemleak_free can be removed too.
Yee Lee (1):
mm: kfence: skip kmemleak alloc in kfence_pool
mm/kfence/core.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool
2022-06-23 11:19 ` yee.lee
@ 2022-06-23 11:19 ` yee.lee
-1 siblings, 0 replies; 13+ messages in thread
From: yee.lee @ 2022-06-23 11:19 UTC (permalink / raw)
To: linux-kernel
Cc: Yee Lee, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, Matthias Brugger, open list:KFENCE,
open list:MEMORY MANAGEMENT,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
From: Yee Lee <yee.lee@mediatek.com>
Use MEMBLOCK_ALLOC_NOLEAKTRACE to skip kmemleak registration when
the kfence pool is allocated from memblock. And the kmemleak_free
later can be removed too.
Signed-off-by: Yee Lee <yee.lee@mediatek.com>
---
mm/kfence/core.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/mm/kfence/core.c b/mm/kfence/core.c
index 4e7cd4c8e687..0d33d83f5244 100644
--- a/mm/kfence/core.c
+++ b/mm/kfence/core.c
@@ -600,14 +600,6 @@ static unsigned long kfence_init_pool(void)
addr += 2 * PAGE_SIZE;
}
- /*
- * The pool is live and will never be deallocated from this point on.
- * Remove the pool object from the kmemleak object tree, as it would
- * otherwise overlap with allocations returned by kfence_alloc(), which
- * are registered with kmemleak through the slab post-alloc hook.
- */
- kmemleak_free(__kfence_pool);
-
return 0;
}
@@ -831,8 +823,14 @@ void __init kfence_alloc_pool(void)
{
if (!kfence_sample_interval)
return;
-
- __kfence_pool = memblock_alloc(KFENCE_POOL_SIZE, PAGE_SIZE);
+ /*
+ * The pool is live and will never be deallocated from this point on.
+ * Skip the pool object from the kmemleak object allocation, as it would
+ * otherwise overlap with allocations returned by kfence_alloc(), which
+ * are registered with kmemleak through the slab post-alloc hook.
+ */
+ __kfence_pool = memblock_alloc_try_nid(KFENCE_POOL_SIZE, PAGE_SIZE,
+ MEMBLOCK_LOW_LIMIT, MEMBLOCK_ALLOC_NOLEAKTRACE, NUMA_NO_NODE);
if (!__kfence_pool)
pr_err("failed to allocate pool\n");
--
2.18.0
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool
@ 2022-06-23 11:19 ` yee.lee
0 siblings, 0 replies; 13+ messages in thread
From: yee.lee @ 2022-06-23 11:19 UTC (permalink / raw)
To: linux-kernel
Cc: Yee Lee, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, Matthias Brugger, open list:KFENCE,
open list:MEMORY MANAGEMENT,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
From: Yee Lee <yee.lee@mediatek.com>
Use MEMBLOCK_ALLOC_NOLEAKTRACE to skip kmemleak registration when
the kfence pool is allocated from memblock. And the kmemleak_free
later can be removed too.
Signed-off-by: Yee Lee <yee.lee@mediatek.com>
---
mm/kfence/core.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/mm/kfence/core.c b/mm/kfence/core.c
index 4e7cd4c8e687..0d33d83f5244 100644
--- a/mm/kfence/core.c
+++ b/mm/kfence/core.c
@@ -600,14 +600,6 @@ static unsigned long kfence_init_pool(void)
addr += 2 * PAGE_SIZE;
}
- /*
- * The pool is live and will never be deallocated from this point on.
- * Remove the pool object from the kmemleak object tree, as it would
- * otherwise overlap with allocations returned by kfence_alloc(), which
- * are registered with kmemleak through the slab post-alloc hook.
- */
- kmemleak_free(__kfence_pool);
-
return 0;
}
@@ -831,8 +823,14 @@ void __init kfence_alloc_pool(void)
{
if (!kfence_sample_interval)
return;
-
- __kfence_pool = memblock_alloc(KFENCE_POOL_SIZE, PAGE_SIZE);
+ /*
+ * The pool is live and will never be deallocated from this point on.
+ * Skip the pool object from the kmemleak object allocation, as it would
+ * otherwise overlap with allocations returned by kfence_alloc(), which
+ * are registered with kmemleak through the slab post-alloc hook.
+ */
+ __kfence_pool = memblock_alloc_try_nid(KFENCE_POOL_SIZE, PAGE_SIZE,
+ MEMBLOCK_LOW_LIMIT, MEMBLOCK_ALLOC_NOLEAKTRACE, NUMA_NO_NODE);
if (!__kfence_pool)
pr_err("failed to allocate pool\n");
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool
2022-06-23 11:19 ` yee.lee
@ 2022-06-23 11:59 ` Marco Elver
-1 siblings, 0 replies; 13+ messages in thread
From: Marco Elver @ 2022-06-23 11:59 UTC (permalink / raw)
To: yee.lee
Cc: linux-kernel, Alexander Potapenko, Dmitry Vyukov, Andrew Morton,
Matthias Brugger, open list:KFENCE, open list:MEMORY MANAGEMENT,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
On Thu, 23 Jun 2022 at 13:20, yee.lee via kasan-dev
<kasan-dev@googlegroups.com> wrote:
>
> From: Yee Lee <yee.lee@mediatek.com>
>
> Use MEMBLOCK_ALLOC_NOLEAKTRACE to skip kmemleak registration when
> the kfence pool is allocated from memblock. And the kmemleak_free
> later can be removed too.
Is this purely meant to be a cleanup and non-functional change?
> Signed-off-by: Yee Lee <yee.lee@mediatek.com>
>
> ---
> mm/kfence/core.c | 18 ++++++++----------
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/mm/kfence/core.c b/mm/kfence/core.c
> index 4e7cd4c8e687..0d33d83f5244 100644
> --- a/mm/kfence/core.c
> +++ b/mm/kfence/core.c
> @@ -600,14 +600,6 @@ static unsigned long kfence_init_pool(void)
> addr += 2 * PAGE_SIZE;
> }
>
> - /*
> - * The pool is live and will never be deallocated from this point on.
> - * Remove the pool object from the kmemleak object tree, as it would
> - * otherwise overlap with allocations returned by kfence_alloc(), which
> - * are registered with kmemleak through the slab post-alloc hook.
> - */
> - kmemleak_free(__kfence_pool);
This appears to only be a non-functional change if the pool is
allocated early. If the pool is allocated late using page-alloc, then
there'll not be a kmemleak_free() on that memory and we'll have the
same problem.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool
@ 2022-06-23 11:59 ` Marco Elver
0 siblings, 0 replies; 13+ messages in thread
From: Marco Elver @ 2022-06-23 11:59 UTC (permalink / raw)
To: yee.lee
Cc: linux-kernel, Alexander Potapenko, Dmitry Vyukov, Andrew Morton,
Matthias Brugger, open list:KFENCE, open list:MEMORY MANAGEMENT,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
On Thu, 23 Jun 2022 at 13:20, yee.lee via kasan-dev
<kasan-dev@googlegroups.com> wrote:
>
> From: Yee Lee <yee.lee@mediatek.com>
>
> Use MEMBLOCK_ALLOC_NOLEAKTRACE to skip kmemleak registration when
> the kfence pool is allocated from memblock. And the kmemleak_free
> later can be removed too.
Is this purely meant to be a cleanup and non-functional change?
> Signed-off-by: Yee Lee <yee.lee@mediatek.com>
>
> ---
> mm/kfence/core.c | 18 ++++++++----------
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/mm/kfence/core.c b/mm/kfence/core.c
> index 4e7cd4c8e687..0d33d83f5244 100644
> --- a/mm/kfence/core.c
> +++ b/mm/kfence/core.c
> @@ -600,14 +600,6 @@ static unsigned long kfence_init_pool(void)
> addr += 2 * PAGE_SIZE;
> }
>
> - /*
> - * The pool is live and will never be deallocated from this point on.
> - * Remove the pool object from the kmemleak object tree, as it would
> - * otherwise overlap with allocations returned by kfence_alloc(), which
> - * are registered with kmemleak through the slab post-alloc hook.
> - */
> - kmemleak_free(__kfence_pool);
This appears to only be a non-functional change if the pool is
allocated early. If the pool is allocated late using page-alloc, then
there'll not be a kmemleak_free() on that memory and we'll have the
same problem.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool
2022-06-23 11:59 ` Marco Elver
@ 2022-06-24 8:20 ` Yee Lee
-1 siblings, 0 replies; 13+ messages in thread
From: Yee Lee @ 2022-06-24 8:20 UTC (permalink / raw)
To: Marco Elver
Cc: linux-kernel, Alexander Potapenko, Dmitry Vyukov, Andrew Morton,
Matthias Brugger, open list:KFENCE, open list:MEMORY MANAGEMENT,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
On Thu, 2022-06-23 at 13:59 +0200, Marco Elver wrote:
> On Thu, 23 Jun 2022 at 13:20, yee.lee via kasan-dev
> <kasan-dev@googlegroups.com> wrote:
> >
> > From: Yee Lee <yee.lee@mediatek.com>
> >
> > Use MEMBLOCK_ALLOC_NOLEAKTRACE to skip kmemleak registration when
> > the kfence pool is allocated from memblock. And the kmemleak_free
> > later can be removed too.
>
> Is this purely meant to be a cleanup and non-functional change?
>
> > Signed-off-by: Yee Lee <yee.lee@mediatek.com>
> >
> > ---
> > mm/kfence/core.c | 18 ++++++++----------
> > 1 file changed, 8 insertions(+), 10 deletions(-)
> >
> > diff --git a/mm/kfence/core.c b/mm/kfence/core.c
> > index 4e7cd4c8e687..0d33d83f5244 100644
> > --- a/mm/kfence/core.c
> > +++ b/mm/kfence/core.c
> > @@ -600,14 +600,6 @@ static unsigned long kfence_init_pool(void)
> > addr += 2 * PAGE_SIZE;
> > }
> >
> > - /*
> > - * The pool is live and will never be deallocated from this
> > point on.
> > - * Remove the pool object from the kmemleak object tree, as
> > it would
> > - * otherwise overlap with allocations returned by
> > kfence_alloc(), which
> > - * are registered with kmemleak through the slab post-alloc
> > hook.
> > - */
> > - kmemleak_free(__kfence_pool);
>
> This appears to only be a non-functional change if the pool is
> allocated early. If the pool is allocated late using page-alloc, then
> there'll not be a kmemleak_free() on that memory and we'll have the
> same problem.
Do you mean the kzalloc(slab_is_available) in memblock_allc()? That
implies that MEMBLOCK_ALLOC_NOLEAKTRACE has no guarantee skipping
kmemleak_alloc from this. (Maybe add it?)
If so, we cannot identify later the block is stored in the phys
tree(memblock) or the virt tree(page_alloc).
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool
@ 2022-06-24 8:20 ` Yee Lee
0 siblings, 0 replies; 13+ messages in thread
From: Yee Lee @ 2022-06-24 8:20 UTC (permalink / raw)
To: Marco Elver
Cc: linux-kernel, Alexander Potapenko, Dmitry Vyukov, Andrew Morton,
Matthias Brugger, open list:KFENCE, open list:MEMORY MANAGEMENT,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
On Thu, 2022-06-23 at 13:59 +0200, Marco Elver wrote:
> On Thu, 23 Jun 2022 at 13:20, yee.lee via kasan-dev
> <kasan-dev@googlegroups.com> wrote:
> >
> > From: Yee Lee <yee.lee@mediatek.com>
> >
> > Use MEMBLOCK_ALLOC_NOLEAKTRACE to skip kmemleak registration when
> > the kfence pool is allocated from memblock. And the kmemleak_free
> > later can be removed too.
>
> Is this purely meant to be a cleanup and non-functional change?
>
> > Signed-off-by: Yee Lee <yee.lee@mediatek.com>
> >
> > ---
> > mm/kfence/core.c | 18 ++++++++----------
> > 1 file changed, 8 insertions(+), 10 deletions(-)
> >
> > diff --git a/mm/kfence/core.c b/mm/kfence/core.c
> > index 4e7cd4c8e687..0d33d83f5244 100644
> > --- a/mm/kfence/core.c
> > +++ b/mm/kfence/core.c
> > @@ -600,14 +600,6 @@ static unsigned long kfence_init_pool(void)
> > addr += 2 * PAGE_SIZE;
> > }
> >
> > - /*
> > - * The pool is live and will never be deallocated from this
> > point on.
> > - * Remove the pool object from the kmemleak object tree, as
> > it would
> > - * otherwise overlap with allocations returned by
> > kfence_alloc(), which
> > - * are registered with kmemleak through the slab post-alloc
> > hook.
> > - */
> > - kmemleak_free(__kfence_pool);
>
> This appears to only be a non-functional change if the pool is
> allocated early. If the pool is allocated late using page-alloc, then
> there'll not be a kmemleak_free() on that memory and we'll have the
> same problem.
Do you mean the kzalloc(slab_is_available) in memblock_allc()? That
implies that MEMBLOCK_ALLOC_NOLEAKTRACE has no guarantee skipping
kmemleak_alloc from this. (Maybe add it?)
If so, we cannot identify later the block is stored in the phys
tree(memblock) or the virt tree(page_alloc).
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool
2022-06-24 8:20 ` Yee Lee
@ 2022-06-24 8:28 ` Marco Elver
-1 siblings, 0 replies; 13+ messages in thread
From: Marco Elver @ 2022-06-24 8:28 UTC (permalink / raw)
To: Yee Lee
Cc: linux-kernel, Alexander Potapenko, Dmitry Vyukov, Andrew Morton,
Matthias Brugger, open list:KFENCE, open list:MEMORY MANAGEMENT,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
On Fri, 24 Jun 2022 at 10:20, 'Yee Lee' via kasan-dev
<kasan-dev@googlegroups.com> wrote:
>
> On Thu, 2022-06-23 at 13:59 +0200, Marco Elver wrote:
> > On Thu, 23 Jun 2022 at 13:20, yee.lee via kasan-dev
> > <kasan-dev@googlegroups.com> wrote:
> > >
> > > From: Yee Lee <yee.lee@mediatek.com>
> > >
> > > Use MEMBLOCK_ALLOC_NOLEAKTRACE to skip kmemleak registration when
> > > the kfence pool is allocated from memblock. And the kmemleak_free
> > > later can be removed too.
> >
> > Is this purely meant to be a cleanup and non-functional change?
> >
> > > Signed-off-by: Yee Lee <yee.lee@mediatek.com>
> > >
> > > ---
> > > mm/kfence/core.c | 18 ++++++++----------
> > > 1 file changed, 8 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/mm/kfence/core.c b/mm/kfence/core.c
> > > index 4e7cd4c8e687..0d33d83f5244 100644
> > > --- a/mm/kfence/core.c
> > > +++ b/mm/kfence/core.c
> > > @@ -600,14 +600,6 @@ static unsigned long kfence_init_pool(void)
> > > addr += 2 * PAGE_SIZE;
> > > }
> > >
> > > - /*
> > > - * The pool is live and will never be deallocated from this
> > > point on.
> > > - * Remove the pool object from the kmemleak object tree, as
> > > it would
> > > - * otherwise overlap with allocations returned by
> > > kfence_alloc(), which
> > > - * are registered with kmemleak through the slab post-alloc
> > > hook.
> > > - */
> > > - kmemleak_free(__kfence_pool);
> >
> > This appears to only be a non-functional change if the pool is
> > allocated early. If the pool is allocated late using page-alloc, then
> > there'll not be a kmemleak_free() on that memory and we'll have the
> > same problem.
>
> Do you mean the kzalloc(slab_is_available) in memblock_allc()? That
> implies that MEMBLOCK_ALLOC_NOLEAKTRACE has no guarantee skipping
> kmemleak_alloc from this. (Maybe add it?)
No, if KFENCE is initialized through kfence_init_late() ->
kfence_init_pool_late() -> kfence_init_pool().
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool
@ 2022-06-24 8:28 ` Marco Elver
0 siblings, 0 replies; 13+ messages in thread
From: Marco Elver @ 2022-06-24 8:28 UTC (permalink / raw)
To: Yee Lee
Cc: linux-kernel, Alexander Potapenko, Dmitry Vyukov, Andrew Morton,
Matthias Brugger, open list:KFENCE, open list:MEMORY MANAGEMENT,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
On Fri, 24 Jun 2022 at 10:20, 'Yee Lee' via kasan-dev
<kasan-dev@googlegroups.com> wrote:
>
> On Thu, 2022-06-23 at 13:59 +0200, Marco Elver wrote:
> > On Thu, 23 Jun 2022 at 13:20, yee.lee via kasan-dev
> > <kasan-dev@googlegroups.com> wrote:
> > >
> > > From: Yee Lee <yee.lee@mediatek.com>
> > >
> > > Use MEMBLOCK_ALLOC_NOLEAKTRACE to skip kmemleak registration when
> > > the kfence pool is allocated from memblock. And the kmemleak_free
> > > later can be removed too.
> >
> > Is this purely meant to be a cleanup and non-functional change?
> >
> > > Signed-off-by: Yee Lee <yee.lee@mediatek.com>
> > >
> > > ---
> > > mm/kfence/core.c | 18 ++++++++----------
> > > 1 file changed, 8 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/mm/kfence/core.c b/mm/kfence/core.c
> > > index 4e7cd4c8e687..0d33d83f5244 100644
> > > --- a/mm/kfence/core.c
> > > +++ b/mm/kfence/core.c
> > > @@ -600,14 +600,6 @@ static unsigned long kfence_init_pool(void)
> > > addr += 2 * PAGE_SIZE;
> > > }
> > >
> > > - /*
> > > - * The pool is live and will never be deallocated from this
> > > point on.
> > > - * Remove the pool object from the kmemleak object tree, as
> > > it would
> > > - * otherwise overlap with allocations returned by
> > > kfence_alloc(), which
> > > - * are registered with kmemleak through the slab post-alloc
> > > hook.
> > > - */
> > > - kmemleak_free(__kfence_pool);
> >
> > This appears to only be a non-functional change if the pool is
> > allocated early. If the pool is allocated late using page-alloc, then
> > there'll not be a kmemleak_free() on that memory and we'll have the
> > same problem.
>
> Do you mean the kzalloc(slab_is_available) in memblock_allc()? That
> implies that MEMBLOCK_ALLOC_NOLEAKTRACE has no guarantee skipping
> kmemleak_alloc from this. (Maybe add it?)
No, if KFENCE is initialized through kfence_init_late() ->
kfence_init_pool_late() -> kfence_init_pool().
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool
2022-06-24 8:28 ` Marco Elver
(?)
@ 2022-06-28 6:40 ` Yee Lee
2022-06-28 7:25 ` Marco Elver
-1 siblings, 1 reply; 13+ messages in thread
From: Yee Lee @ 2022-06-28 6:40 UTC (permalink / raw)
To: Marco Elver
Cc: linux-kernel, Alexander Potapenko, Dmitry Vyukov, Andrew Morton,
Matthias Brugger, open list:KFENCE, open list:MEMORY MANAGEMENT,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, catalin.marinas
[-- Attachment #1: Type: text/plain, Size: 5253 bytes --]
On Fri, 2022-06-24 at 10:28 +0200, Marco Elver wrote:
> On Fri, 24 Jun 2022 at 10:20, 'Yee Lee' via kasan-dev
> <kasan-dev@googlegroups.com> wrote:
> >
> > On Thu, 2022-06-23 at 13:59 +0200, Marco Elver wrote:
> > > On Thu, 23 Jun 2022 at 13:20, yee.lee via kasan-dev
> > > <kasan-dev@googlegroups.com> wrote:
> > > >
> > > > From: Yee Lee <yee.lee@mediatek.com>
> > > >
> > > > Use MEMBLOCK_ALLOC_NOLEAKTRACE to skip kmemleak registration
> > > > when
> > > > the kfence pool is allocated from memblock. And the
> > > > kmemleak_free
> > > > later can be removed too.
> > >
> > > Is this purely meant to be a cleanup and non-functional change?
> > >
> > > > Signed-off-by: Yee Lee <yee.lee@mediatek.com>
> > > >
> > > > ---
> > > > mm/kfence/core.c | 18 ++++++++----------
> > > > 1 file changed, 8 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/mm/kfence/core.c b/mm/kfence/core.c
> > > > index 4e7cd4c8e687..0d33d83f5244 100644
> > > > --- a/mm/kfence/core.c
> > > > +++ b/mm/kfence/core.c
> > > > @@ -600,14 +600,6 @@ static unsigned long
> > > > kfence_init_pool(void)
> > > > addr += 2 * PAGE_SIZE;
> > > > }
> > > >
> > > > - /*
> > > > - * The pool is live and will never be deallocated from
> > > > this
> > > > point on.
> > > > - * Remove the pool object from the kmemleak object
> > > > tree, as
> > > > it would
> > > > - * otherwise overlap with allocations returned by
> > > > kfence_alloc(), which
> > > > - * are registered with kmemleak through the slab post-
> > > > alloc
> > > > hook.
> > > > - */
> > > > - kmemleak_free(__kfence_pool);
> > >
> > > This appears to only be a non-functional change if the pool is
> > > allocated early. If the pool is allocated late using page-alloc,
> > > then
> > > there'll not be a kmemleak_free() on that memory and we'll have
> > > the
> > > same problem.
> >
> > Do you mean the kzalloc(slab_is_available) in memblock_allc()? That
> > implies that MEMBLOCK_ALLOC_NOLEAKTRACE has no guarantee skipping
> > kmemleak_alloc from this. (Maybe add it?)
>
> No, if KFENCE is initialized through kfence_init_late() ->
> kfence_init_pool_late() -> kfence_init_pool().
Thanks for the information.
But as I known, page-alloc does not request kmemleak areas.
So the current kfence_pool_init_late() would cause another kmemleak
warning on unknown freeing.
Reproducing test: (kfence late enable + kmemleak debug on)
/ # echo 500 > /sys/module/kfence/parameters/sample_interval
[ 153.433518] kmemleak: Freeing unknown object at 0xffff0000c0600000
[ 153.433804] CPU: 0 PID: 100 Comm: sh Not tainted 5.19.0-rc3-74069-
gde5c208d533a-dirty #1
[ 153.434027] Hardware name: linux,dummy-virt (DT)
[ 153.434265] Call trace:
[ 153.434331] dump_backtrace+0xdc/0xfc
[ 153.434962] show_stack+0x18/0x24
[ 153.435106] dump_stack_lvl+0x64/0x7c
[ 153.435232] dump_stack+0x18/0x38
[ 153.435347] kmemleak_free+0x184/0x1c8
[ 153.435462] kfence_init_pool+0x16c/0x194
[ 153.435587] param_set_sample_interval+0xe0/0x1c4
[ 153.435694] param_attr_store+0x98/0xf4
[ 153.435804] module_attr_store+0x24/0x3c
[ 153.435910] sysfs_kf_write+0x3c/0x50
...(skip)
[ 153.444496] kfence: initialized - using 524288 bytes for 63 objects
at 0x00000000a3236b01-0x00000000901655d3
/ #
Hence, now there are two issues to solve.
(1) (The original)To prevent the undesired kmemleak scanning on the
kfence pool. As Cataline's suggestion, we can just apply
kmemleak_ignore_phys instead of free it at all.
ref: https://lore.kernel.org/linux-mm/YrWPg3xIHbm9bFxP@arm.com/
(2) The late-allocated kfence pool doesn't need to go through
kmemleak_free. We can relocate the opeartion to
kfence_init_pool_early() to seperate them.
That is, kfence_init_pool_early(memblock) has it and
kfence_init_pool_late(page alloc) does not.
The draft is like the following.
diff --git a/mm/kfence/core.c b/mm/kfence/core.c
index 11a954763be9..a52db7f06c04 100644
--- a/mm/kfence/core.c
+++ b/mm/kfence/core.c
@@ -591,14 +591,6 @@ static unsigned long kfence_init_pool(void)
addr += 2 * PAGE_SIZE;
}
- /*
- * The pool is live and will never be deallocated from this
point on.
- * Remove the pool object from the kmemleak object tree, as it
would
- * otherwise overlap with allocations returned by
kfence_alloc(), which
- * are registered with kmemleak through the slab post-alloc
hook.
- */
- kmemleak_free(__kfence_pool);
-
return 0;
}
@@ -611,8 +603,16 @@ static bool __init kfence_init_pool_early(void)
addr = kfence_init_pool();
- if (!addr)
+ if (!addr) {
+ /*
+ * The pool is live and will never be deallocated from
this point on.
+ * Ignore the pool object from the kmemleak phys object
tree, as it would
+ * otherwise overlap with allocations returned by
kfence_alloc(), which
+ * are registered with kmemleak through the slab post-
alloc hook.
+ */
+ kmemleak_ignore_phys(__pa(__kfence_pool));
return true;
+ }
/*
* Only release unprotected pages, and do not try to go back
and change
[-- Attachment #2: Type: text/html, Size: 9103 bytes --]
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool
2022-06-28 6:40 ` Yee Lee
@ 2022-06-28 7:25 ` Marco Elver
0 siblings, 0 replies; 13+ messages in thread
From: Marco Elver @ 2022-06-28 7:25 UTC (permalink / raw)
To: Yee Lee
Cc: linux-kernel, Alexander Potapenko, Dmitry Vyukov, Andrew Morton,
Matthias Brugger, open list:KFENCE, open list:MEMORY MANAGEMENT,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, catalin.marinas
On Tue, 28 Jun 2022 at 08:41, Yee Lee <yee.lee@mediatek.com> wrote:
>
> On Fri, 2022-06-24 at 10:28 +0200, Marco Elver wrote:
>
> On Fri, 24 Jun 2022 at 10:20, 'Yee Lee' via kasan-dev
> <kasan-dev@googlegroups.com> wrote:
>
>
> On Thu, 2022-06-23 at 13:59 +0200, Marco Elver wrote:
>
> On Thu, 23 Jun 2022 at 13:20, yee.lee via kasan-dev
> <kasan-dev@googlegroups.com> wrote:
>
>
> From: Yee Lee <yee.lee@mediatek.com>
>
> Use MEMBLOCK_ALLOC_NOLEAKTRACE to skip kmemleak registration when
> the kfence pool is allocated from memblock. And the kmemleak_free
> later can be removed too.
>
>
> Is this purely meant to be a cleanup and non-functional change?
>
> Signed-off-by: Yee Lee <yee.lee@mediatek.com>
>
> ---
> mm/kfence/core.c | 18 ++++++++----------
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/mm/kfence/core.c b/mm/kfence/core.c
> index 4e7cd4c8e687..0d33d83f5244 100644
> --- a/mm/kfence/core.c
> +++ b/mm/kfence/core.c
> @@ -600,14 +600,6 @@ static unsigned long kfence_init_pool(void)
> addr += 2 * PAGE_SIZE;
> }
>
> - /*
> - * The pool is live and will never be deallocated from this
> point on.
> - * Remove the pool object from the kmemleak object tree, as
> it would
> - * otherwise overlap with allocations returned by
> kfence_alloc(), which
> - * are registered with kmemleak through the slab post-alloc
> hook.
> - */
> - kmemleak_free(__kfence_pool);
>
>
> This appears to only be a non-functional change if the pool is
> allocated early. If the pool is allocated late using page-alloc, then
> there'll not be a kmemleak_free() on that memory and we'll have the
> same problem.
>
>
> Do you mean the kzalloc(slab_is_available) in memblock_allc()? That
> implies that MEMBLOCK_ALLOC_NOLEAKTRACE has no guarantee skipping
> kmemleak_alloc from this. (Maybe add it?)
>
>
> No, if KFENCE is initialized through kfence_init_late() ->
> kfence_init_pool_late() -> kfence_init_pool().
>
> Thanks for the information.
>
> But as I known, page-alloc does not request kmemleak areas.
> So the current kfence_pool_init_late() would cause another kmemleak warning on unknown freeing.
>
> Reproducing test: (kfence late enable + kmemleak debug on)
>
> / # echo 500 > /sys/module/kfence/parameters/sample_interval
> [ 153.433518] kmemleak: Freeing unknown object at 0xffff0000c0600000
> [ 153.433804] CPU: 0 PID: 100 Comm: sh Not tainted 5.19.0-rc3-74069-gde5c208d533a-dirty #1
> [ 153.434027] Hardware name: linux,dummy-virt (DT)
> [ 153.434265] Call trace:
> [ 153.434331] dump_backtrace+0xdc/0xfc
> [ 153.434962] show_stack+0x18/0x24
> [ 153.435106] dump_stack_lvl+0x64/0x7c
> [ 153.435232] dump_stack+0x18/0x38
> [ 153.435347] kmemleak_free+0x184/0x1c8
> [ 153.435462] kfence_init_pool+0x16c/0x194
> [ 153.435587] param_set_sample_interval+0xe0/0x1c4
> [ 153.435694] param_attr_store+0x98/0xf4
> [ 153.435804] module_attr_store+0x24/0x3c
> [ 153.435910] sysfs_kf_write+0x3c/0x50
> ...(skip)
> [ 153.444496] kfence: initialized - using 524288 bytes for 63 objects at 0x00000000a3236b01-0x00000000901655d3
> / #
>
> Hence, now there are two issues to solve.
> (1) (The original)To prevent the undesired kmemleak scanning on the kfence pool. As Cataline's suggestion, we can just apply kmemleak_ignore_phys instead of free it at all.
> ref: https://lore.kernel.org/linux-mm/YrWPg3xIHbm9bFxP@arm.com/
>
> (2) The late-allocated kfence pool doesn't need to go through kmemleak_free. We can relocate the opeartion to kfence_init_pool_early() to seperate them.
> That is, kfence_init_pool_early(memblock) has it and kfence_init_pool_late(page alloc) does not.
>
> The draft is like the following.
Looks reasonable - feel free to send v2.
Thanks,
-- Marco
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool
@ 2022-06-28 7:25 ` Marco Elver
0 siblings, 0 replies; 13+ messages in thread
From: Marco Elver @ 2022-06-28 7:25 UTC (permalink / raw)
To: Yee Lee
Cc: linux-kernel, Alexander Potapenko, Dmitry Vyukov, Andrew Morton,
Matthias Brugger, open list:KFENCE, open list:MEMORY MANAGEMENT,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, catalin.marinas
On Tue, 28 Jun 2022 at 08:41, Yee Lee <yee.lee@mediatek.com> wrote:
>
> On Fri, 2022-06-24 at 10:28 +0200, Marco Elver wrote:
>
> On Fri, 24 Jun 2022 at 10:20, 'Yee Lee' via kasan-dev
> <kasan-dev@googlegroups.com> wrote:
>
>
> On Thu, 2022-06-23 at 13:59 +0200, Marco Elver wrote:
>
> On Thu, 23 Jun 2022 at 13:20, yee.lee via kasan-dev
> <kasan-dev@googlegroups.com> wrote:
>
>
> From: Yee Lee <yee.lee@mediatek.com>
>
> Use MEMBLOCK_ALLOC_NOLEAKTRACE to skip kmemleak registration when
> the kfence pool is allocated from memblock. And the kmemleak_free
> later can be removed too.
>
>
> Is this purely meant to be a cleanup and non-functional change?
>
> Signed-off-by: Yee Lee <yee.lee@mediatek.com>
>
> ---
> mm/kfence/core.c | 18 ++++++++----------
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/mm/kfence/core.c b/mm/kfence/core.c
> index 4e7cd4c8e687..0d33d83f5244 100644
> --- a/mm/kfence/core.c
> +++ b/mm/kfence/core.c
> @@ -600,14 +600,6 @@ static unsigned long kfence_init_pool(void)
> addr += 2 * PAGE_SIZE;
> }
>
> - /*
> - * The pool is live and will never be deallocated from this
> point on.
> - * Remove the pool object from the kmemleak object tree, as
> it would
> - * otherwise overlap with allocations returned by
> kfence_alloc(), which
> - * are registered with kmemleak through the slab post-alloc
> hook.
> - */
> - kmemleak_free(__kfence_pool);
>
>
> This appears to only be a non-functional change if the pool is
> allocated early. If the pool is allocated late using page-alloc, then
> there'll not be a kmemleak_free() on that memory and we'll have the
> same problem.
>
>
> Do you mean the kzalloc(slab_is_available) in memblock_allc()? That
> implies that MEMBLOCK_ALLOC_NOLEAKTRACE has no guarantee skipping
> kmemleak_alloc from this. (Maybe add it?)
>
>
> No, if KFENCE is initialized through kfence_init_late() ->
> kfence_init_pool_late() -> kfence_init_pool().
>
> Thanks for the information.
>
> But as I known, page-alloc does not request kmemleak areas.
> So the current kfence_pool_init_late() would cause another kmemleak warning on unknown freeing.
>
> Reproducing test: (kfence late enable + kmemleak debug on)
>
> / # echo 500 > /sys/module/kfence/parameters/sample_interval
> [ 153.433518] kmemleak: Freeing unknown object at 0xffff0000c0600000
> [ 153.433804] CPU: 0 PID: 100 Comm: sh Not tainted 5.19.0-rc3-74069-gde5c208d533a-dirty #1
> [ 153.434027] Hardware name: linux,dummy-virt (DT)
> [ 153.434265] Call trace:
> [ 153.434331] dump_backtrace+0xdc/0xfc
> [ 153.434962] show_stack+0x18/0x24
> [ 153.435106] dump_stack_lvl+0x64/0x7c
> [ 153.435232] dump_stack+0x18/0x38
> [ 153.435347] kmemleak_free+0x184/0x1c8
> [ 153.435462] kfence_init_pool+0x16c/0x194
> [ 153.435587] param_set_sample_interval+0xe0/0x1c4
> [ 153.435694] param_attr_store+0x98/0xf4
> [ 153.435804] module_attr_store+0x24/0x3c
> [ 153.435910] sysfs_kf_write+0x3c/0x50
> ...(skip)
> [ 153.444496] kfence: initialized - using 524288 bytes for 63 objects at 0x00000000a3236b01-0x00000000901655d3
> / #
>
> Hence, now there are two issues to solve.
> (1) (The original)To prevent the undesired kmemleak scanning on the kfence pool. As Cataline's suggestion, we can just apply kmemleak_ignore_phys instead of free it at all.
> ref: https://lore.kernel.org/linux-mm/YrWPg3xIHbm9bFxP@arm.com/
>
> (2) The late-allocated kfence pool doesn't need to go through kmemleak_free. We can relocate the opeartion to kfence_init_pool_early() to seperate them.
> That is, kfence_init_pool_early(memblock) has it and kfence_init_pool_late(page alloc) does not.
>
> The draft is like the following.
Looks reasonable - feel free to send v2.
Thanks,
-- Marco
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-06-28 7:27 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-23 11:19 [PATCH 0/1] mm: kfence: remove kfence_pool from leak trace yee.lee
2022-06-23 11:19 ` yee.lee
2022-06-23 11:19 ` [PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool yee.lee
2022-06-23 11:19 ` yee.lee
2022-06-23 11:59 ` Marco Elver
2022-06-23 11:59 ` Marco Elver
2022-06-24 8:20 ` Yee Lee
2022-06-24 8:20 ` Yee Lee
2022-06-24 8:28 ` Marco Elver
2022-06-24 8:28 ` Marco Elver
2022-06-28 6:40 ` Yee Lee
2022-06-28 7:25 ` Marco Elver
2022-06-28 7:25 ` Marco Elver
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.