From: Muchun Song <muchun.song@linux.dev>
To: Chris Down <chris@chrisdown.name>
Cc: Muchun Song <songmuchun@bytedance.com>,
Alexander Potapenko <glider@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Marco Elver <elver@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
David Hildenbrand <david@kernel.org>,
"Liam R . Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Brendan Jackman <brendan.jackman@linux.dev>,
Zi Yan <ziy@nvidia.com>, Sang-Heon Jeon <ekffu200098@gmail.com>,
Mostafa Saleh <smostafa@google.com>,
Ketan <ketan.kishore@oss.qualcomm.com>,
Usama Arif <usama.arif@bytedance.com>,
kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH 2/3] mm/page_ext: support early allocation for SPARSEMEM
Date: Sun, 15 Nov 2026 14:44:45 +0800 [thread overview]
Message-ID: <90DD8319-BE49-4355-8CFF-36B7AA9BA4EA@linux.dev> (raw)
In-Reply-To: <20261114222344.e65dbc73bf2c9276@chrisdown.name>
> On Nov 15, 2026, at 14:23, Chris Down <chris@chrisdown.name> wrote:
>
> Hi Muchun,
Hi,
>
> This looks good to me in general, I only have a few small things.
Thanks for taking a look.
>
> Muchun Song writes:
>> - /*
>> - * page_owner must be initialized after buddy is ready, and also after
>> - * slab is ready so that stack_depot_init() works properly
>> - */
>> - page_ext_init_flatmem_late();
>
> Not a big deal, but this means that on FLATMEM the init callbacks now run
> after vmalloc_init() rather than straight after kmem_cache_init(). I can't
> see anything that depends on the old place, but FLATMEM isn't what the
> patch is about, so it'd be good to say in the changelog that this moves.
Sure. The new behavior is aligned with the non-FLATMEM case. It should be fine.
>
>> + if (!slab_is_available()) {
>> + addr = memblock_alloc_try_nid(size, PAGE_SIZE, 0,
>> + MEMBLOCK_ALLOC_ACCESSIBLE, nid);
>
> Maybe this should pass __pa(MAX_DMA_ADDRESS) as min_addr, like
> alloc_node_page_ext() does, so that the tables stay out of ZONE_DMA when
> there's room elsewhere?
Make sense.
>
>> + page = virt_to_page(addr);
>> + if (PageReserved(page)) {
>> + memmap_boot_pages_add(-nr_pages);
>> + kmemleak_free_part_phys(__pa(addr), table_size);
>> + free_reserved_area(addr, addr + table_size, -1, "page_ext");
>> + return;
>
> free_reserved_area() prints "Freeing page_ext memory" when it's given a
> name, and this runs once for every section, so offlining a few gigabytes
> would put dozens of those in the log. I think it should pass NULL instead.
Good point. I'll pass NULL in v2.
>
> Did you manage to get this branch to run, by the way? KMSAN is the only
No. I only verified that the KMSCN kernel boots successfully.
> user of need_early, and from a quick check offlining a memory block on a
> KMSAN kernel fails with EBUSY, presumably because the metadata pages can't
> be migrated, so I couldn't exercise it myself.
I'll exercise this code on this path and report back.
>
> Once the changelog and the log message are fixed, please feel free to add:
>
> Reviewed-by: Chris Down <chris@chrisdown.name>
Thanks for your review.
Muchun
>
> Thanks!
>
> Chris
next prev parent reply other threads:[~2026-11-15 6:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-14 10:41 [PATCH 0/3] KMSAN: Move per-page metadata out of struct page Muchun Song
2026-11-14 10:41 ` [PATCH 1/3] kmsan: encapsulate per-page metadata access Muchun Song
2026-11-15 6:23 ` Chris Down
2026-11-14 10:41 ` [PATCH 2/3] mm/page_ext: support early allocation for SPARSEMEM Muchun Song
2026-11-15 6:23 ` Chris Down
2026-11-15 6:44 ` Muchun Song [this message]
2026-11-14 10:41 ` [PATCH 3/3] kmsan: fix metadata loss during HugeTLB struct page reinitialization Muchun Song
2026-11-15 6:23 ` Chris Down
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=90DD8319-BE49-4355-8CFF-36B7AA9BA4EA@linux.dev \
--to=muchun.song@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=brendan.jackman@linux.dev \
--cc=chris@chrisdown.name \
--cc=david@kernel.org \
--cc=dvyukov@google.com \
--cc=ekffu200098@gmail.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=hannes@cmpxchg.org \
--cc=kasan-dev@googlegroups.com \
--cc=ketan.kishore@oss.qualcomm.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=smostafa@google.com \
--cc=songmuchun@bytedance.com \
--cc=surenb@google.com \
--cc=usama.arif@bytedance.com \
--cc=vbabka@kernel.org \
--cc=ziy@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.