Re: [PATCH v2] mm/alloc_tag: clear codetag for pages allocated before page_ext initialization

[Andrew Morton <akpm@linux-foundation.org>]

On Thu, 26 Mar 2026 22:05:54 +0800 Hao Ge <hao.ge@linux.dev> wrote:

> Due to initialization ordering, page_ext is allocated and initialized
> relatively late during boot. Some pages have already been allocated
> and freed before page_ext becomes available, leaving their codetag
> uninitialized.
> 
> A clear example is in init_section_page_ext(): alloc_page_ext() calls
> kmemleak_alloc(). If the slab cache has no free objects, it falls back
> to the buddy allocator to allocate memory. However, at this point page_ext
> is not yet fully initialized, so these newly allocated pages have no
> codetag set. These pages may later be reclaimed by KASAN, which causes
> the warning to trigger when they are freed because their codetag ref is
> still empty.
> 
> Use a global array to track pages allocated before page_ext is fully
> initialized. The array size is fixed at 8192 entries, and will emit
> a warning if this limit is exceeded. When page_ext initialization
> completes, set their codetag to empty to avoid warnings when they
> are freed later.
> 

Thanks.  I'll queue this for review and test.

But where will I queue it?

> 
> Fixes: 93d5440ece3c ("alloc_tag: uninline code gated by mem_alloc_profiling_key in page allocator")

A year ago, so a cc:stable might be needed.

> +#ifdef CONFIG_MEM_ALLOC_PROFILING_DEBUG

otoh, it appears that the bug only hits with
CONFIG_MEM_ALLOC_PROFILING_DEBUG=y?  If so, I'll add that (important)
info to the changelog.

Do people use CONFIG_MEM_ALLOC_PROFILING_DEBUG much?  Is a backport
really needed?

Either way, it seems that this isn't a very urgent issue so I'm
inclined to add it to the 7.1-rc1 pile, perhaps with a cc:stable.

Please all share your thoughts with me, thanks.