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

[yee...@mediatek.com]

From: Yee Lee <yee...@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...@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

[Marco Elver]

On Thu, 23 Jun 2022 at 13:20, yee.lee via kasan-dev
<kasa...@googlegroups.com> wrote:
>
> From: Yee Lee <yee...@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...@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.

[Yee Lee]

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

[Marco Elver]

No, if KFENCE is initialized through kfence_init_late() ->
kfence_init_pool_late() -> kfence_init_pool().

[Yee Lee]

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/YrWPg3xI...@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

[Marco Elver]

Looks reasonable - feel free to send v2.

Thanks,
-- Marco