public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Hao Ge <hao.ge@linux.dev>
Cc: Suren Baghdasaryan <surenb@google.com>,
	Kent Overstreet <kent.overstreet@linux.dev>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/alloc_tag: clear codetag for pages allocated before page_ext initialization
Date: Thu, 19 Mar 2026 15:28:08 -0700	[thread overview]
Message-ID: <20260319152808.fce61386fdf2934d7a3b0edb@linux-foundation.org> (raw)
In-Reply-To: <20260319083153.2488005-1-hao.ge@linux.dev>

On Thu, 19 Mar 2026 16:31:53 +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, similar to how kmemleak tracks early allocations.
> When page_ext initialization completes, set their codetag
> to empty to avoid warnings when they are freed later.
> 
> ...
>
> --- a/include/linux/alloc_tag.h
> +++ b/include/linux/alloc_tag.h
> @@ -74,6 +74,9 @@ static inline void set_codetag_empty(union codetag_ref *ref)
>  
>  #ifdef CONFIG_MEM_ALLOC_PROFILING
>  
> +bool mem_profiling_is_available(void);
> +void alloc_tag_add_early_pfn(unsigned long pfn);
> +
>  #define ALLOC_TAG_SECTION_NAME	"alloc_tags"
>  
>  struct codetag_bytes {
> diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
> index 58991ab09d84..a5bf4e72c154 100644
> --- a/lib/alloc_tag.c
> +++ b/lib/alloc_tag.c
> @@ -6,6 +6,7 @@
>  #include <linux/kallsyms.h>
>  #include <linux/module.h>
>  #include <linux/page_ext.h>
> +#include <linux/pgalloc_tag.h>
>  #include <linux/proc_fs.h>
>  #include <linux/seq_buf.h>
>  #include <linux/seq_file.h>
> @@ -26,6 +27,82 @@ static bool mem_profiling_support;
>  
>  static struct codetag_type *alloc_tag_cttype;
>  
> +/*
> + * State of the alloc_tag
> + *
> + * This is used to describe the states of the alloc_tag during bootup.
> + *
> + * When we need to allocate page_ext to store codetag, we face an
> + * initialization timing problem:
> + *
> + * Due to initialization order, pages may be allocated via buddy system
> + * before page_ext is fully allocated and initialized. Although these
> + * pages call the allocation hooks, the codetag will not be set because
> + * page_ext is not yet available.
> + *
> + * When these pages are later free to the buddy system, it triggers
> + * warnings because their codetag is actually empty if
> + * CONFIG_MEM_ALLOC_PROFILING_DEBUG is enabled.
> + *
> + * Additionally, in this situation, we cannot record detailed allocation
> + * information for these pages.
> + */
> +enum mem_profiling_state {
> +	DOWN,			/* No mem_profiling functionality yet */
> +	UP			/* Everything is working */
> +};
> +
> +static enum mem_profiling_state mem_profiling_state = DOWN;
> +
> +bool mem_profiling_is_available(void)
> +{
> +	return mem_profiling_state == UP;
> +}
> +
> +#ifdef CONFIG_MEM_ALLOC_PROFILING_DEBUG
> +
> +#define EARLY_ALLOC_PFN_MAX		256
> +
> +static unsigned long early_pfns[EARLY_ALLOC_PFN_MAX];

It's unfortunate that this isn't __initdata.

> +static unsigned int early_pfn_count;
> +static DEFINE_SPINLOCK(early_pfn_lock);
> +
>
> ...
>
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1293,6 +1293,13 @@ void __pgalloc_tag_add(struct page *page, struct task_struct *task,
>  		alloc_tag_add(&ref, task->alloc_tag, PAGE_SIZE * nr);
>  		update_page_tag_ref(handle, &ref);
>  		put_page_tag_ref(handle);
> +	} else {
> +		/*
> +		 * page_ext is not available yet, record the pfn so we can
> +		 * clear the tag ref later when page_ext is initialized.
> +		 */
> +		if (!mem_profiling_is_available())
> +			alloc_tag_add_early_pfn(page_to_pfn(page));
>  	}
>  }

All because of this, I believe.  Is this fixable?

If we take that `else', we know we're running in __init code, yes?  I
don't see how `__init pgalloc_tag_add_early()' could be made to work. 
hrm.  Something clever, please.



  reply	other threads:[~2026-03-19 22:28 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-19  8:31 [PATCH] mm/alloc_tag: clear codetag for pages allocated before page_ext initialization Hao Ge
2026-03-19 22:28 ` Andrew Morton [this message]
2026-03-19 23:44   ` Suren Baghdasaryan
2026-03-19 23:48     ` Suren Baghdasaryan
2026-03-20  1:57       ` Hao Ge
2026-03-20  2:14         ` Suren Baghdasaryan
2026-03-23  9:15           ` Hao Ge
2026-03-23 22:47             ` Suren Baghdasaryan
2026-03-24  9:43               ` Hao Ge
2026-03-25  0:21                 ` Suren Baghdasaryan
2026-03-25  2:07                   ` Hao Ge
2026-03-25  6:25                     ` Suren Baghdasaryan
2026-03-25  7:35                       ` Suren Baghdasaryan
2026-03-25 11:20                         ` Hao Ge
2026-03-25 15:17                           ` Suren Baghdasaryan
2026-03-26  1:44                             ` Hao Ge
2026-03-26  5:04                               ` Suren Baghdasaryan
2026-03-26  5:33                                 ` Hao Ge
2026-03-26  8:23                                   ` Suren Baghdasaryan
2026-03-20  3:14 ` Andrew Morton
2026-03-20  4:18   ` Suren Baghdasaryan
  -- strict thread matches above, loose matches on Subject: below --
2026-03-27  8:06 Hao Ge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260319152808.fce61386fdf2934d7a3b0edb@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=hao.ge@linux.dev \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=surenb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox