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?) If so, we cannot identify later the block is stored in the phys tree(memblock) or the virt tree(page_alloc).
