On Fri, 24 Jun 2022 at 10:20, 'Yee Lee' via kasan-dev <kasan-dev@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx> wrote: > > > > > > From: Yee Lee <yee.lee@xxxxxxxxxxxx> > > > > > > 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@xxxxxxxxxxxx> > > > > > > --- > > > 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().
