[PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool

[PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool

[yee.lee]

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

Re: [PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool

[Marco Elver]

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.

Re: [PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool

[Yee Lee]

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).

Re: [PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool

[Marco Elver]

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().

Re: [PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool

[Yee Lee]

[-- 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 --]

Re: [PATCH 1/1] mm: kfence: skip kmemleak alloc in kfence_pool

[Marco Elver]

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