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 20:14:34 -0700 [thread overview]
Message-ID: <20260319201434.b51833a0fea2801a2b220ee5@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.
AI review asks questions:
https://sashiko.dev/#/patchset/20260319083153.2488005-1-hao.ge%40linux.dev
next prev parent reply other threads:[~2026-03-20 3:14 UTC|newest]
Thread overview: 21+ 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
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 [this message]
2026-03-20 4:18 ` Suren Baghdasaryan
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=20260319201434.b51833a0fea2801a2b220ee5@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