From: Muchun Song <muchun.song@linux.dev>
To: Mike Rapoport <rppt@kernel.org>
Cc: Muchun Song <songmuchun@bytedance.com>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
Christophe Leroy <chleroy@kernel.org>,
Ritesh Harjani <ritesh.list@gmail.com>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R . Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Qi Zheng <qi.zheng@linux.dev>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v3 6/6] mm/mm_init: add zone mismatch warning during page init
Date: Fri, 2 Oct 2026 17:56:40 +0800 [thread overview]
Message-ID: <85941AA4-7E50-4AAE-BC05-0F443B21BE8B@linux.dev> (raw)
In-Reply-To: <ar9p39Y9SmlxvbA_@kernel.org>
> On Oct 2, 2026, at 16:22, Mike Rapoport <rppt@kernel.org> wrote:
>
> On Fri, Oct 02, 2026 at 09:48:42AM +0800, Muchun Song wrote:
>>
>>
>>> On Oct 1, 2026, at 22:42, Mike Rapoport <rppt@kernel.org> wrote:
>>>
>>> Hi Muchun,
>>
>> Hi,
>>
>>>
>>> On Tue, Sep 29, 2026 at 01:32:31PM +0800, Muchun Song wrote:
>>>> For vmemmap-optimized sections, tail struct pages may be backed by
>>>> shared vmemmap pages. Those shared pages must carry the same page zone
>>>> ID as the struct pages initialized for the section.
>>>>
>>>> Warn in __init_single_page() if the shared tail page has a different
>>>> page_zone_id(), which would indicate inconsistent initialization.
>>>>
>>>> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
>>>> Acked-by: Qi Zheng <qi.zheng@linux.dev>
>>>> ---
>>>> v3:
>>>> - Collect Acked-by from Qi Zheng
>>>>
>>>> v2:
>>>> - New patch.
>>>> ---
>>>> mm/mm_init.c | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/mm/mm_init.c b/mm/mm_init.c
>>>> index 1650d6bc1211..bd02e8d06965 100644
>>>> --- a/mm/mm_init.c
>>>> +++ b/mm/mm_init.c
>>>> @@ -609,6 +609,9 @@ void __meminit __init_single_page(struct page *page, unsigned long pfn,
>>>> if (!is_highmem_idx(zone))
>>>> set_page_address(page, __va(pfn << PAGE_SHIFT));
>>>> #endif
>>>> + VM_WARN_ON_ONCE(vmemmap_optimizable_order(pfn_to_section_compound_order(pfn)) &&
>>>> + page_zone_id(page + VMEMMAP_OPTIMIZATION_NR_STRUCT_PAGES) !=
>>>> + page_zone_id(page));
>>>
>>> Hmm, page + VMEMMAP_OPTIMIZATION_NR_STRUCT_PAGES is initialized a tad later
>>> than page so it'll have stale data in the page->flags, won't it?
>>
>> Lance is right. The shared tail struct pages are already initialized by
>> vmemmap_shared_tail_page() during vmemmap population, so they're not stale.
>> The head 64 struct pages are initialized later — right here, after vmemmap
>> population.
>
> Still it looks out of place here, can this check be done in sparse-vmemmap
> somehow?
The struct page entries of a vmemmap-optimizable compound page
are currently initialized in two stages. During vmemmap
population, the shared tail entries are initialized first. The
retained head area—normally 64—is initialized later through
__init_single_page().
This warning connects the two stages: while initializing the
retained entries in the second stage, it verifies that their zone
information is consistent with the shared entries initialized in
the first stage. Therefore, the same check cannot be performed
during vmemmap population.
I am planning to first unify the HugeTLB and Device DAX
compound-page initialization through a common helper [1]. Once that
work is complete, maybe it will be easy to move the initialization
of the retained head area into vmemmap population. With both the
retained and shared entries initialized in the same stage, there
will be no cross-stage inconsistency to check, and this warning
can be removed.
Would keeping the check here for now and removing it as part of
that follow-up sound reasonable to you?
[1] https://lore.kernel.org/20260513132044.41690-18-songmuchun@bytedance.com/
Thanks,
Muchun
>
>> Thanks,
>> Muchun
>>
>>>
>>>> }
>>>>
>>>> #ifdef CONFIG_NUMA
>>>> --
>>>> 2.54.0
>>>>
>>>
>>> --
>>> Sincerely yours,
>>> Mike.
>>
>>
>
> --
> Sincerely yours,
> Mike.
next prev parent reply other threads:[~2026-10-02 9:57 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 5:32 [PATCH v3 0/6] mm: Unify device DAX and HugeTLB vmemmap population paths Muchun Song
2026-09-29 5:32 ` [PATCH v3 1/6] mm/sparse-vmemmap: drop VMEMMAP_POPULATE_DAX Muchun Song
2026-09-30 4:24 ` Lance Yang
2026-09-29 5:32 ` [PATCH v3 2/6] mm/sparse-vmemmap: support device DAX in common vmemmap path Muchun Song
2026-09-30 8:53 ` Lance Yang
2026-09-30 10:09 ` Muchun Song
2026-09-30 11:11 ` Muchun Song
2026-09-30 13:38 ` Lance Yang
2026-09-30 10:02 ` Lance Yang
2026-09-29 5:32 ` [PATCH v3 3/6] mm/sparse-vmemmap: drop Device DAX-specific population path Muchun Song
2026-10-01 14:27 ` Lance Yang
2026-09-29 5:32 ` [PATCH v3 4/6] mm/sparse-vmemmap: remove the unused ptpfn argument Muchun Song
2026-10-01 14:52 ` Lance Yang
2026-09-29 5:32 ` [PATCH v3 5/6] mm/sparse-vmemmap: open-code vmemmap_populate_address() Muchun Song
2026-10-01 15:10 ` Lance Yang
2026-09-29 5:32 ` [PATCH v3 6/6] mm/mm_init: add zone mismatch warning during page init Muchun Song
2026-10-01 14:42 ` Mike Rapoport
2026-10-01 16:07 ` Lance Yang
2026-10-02 1:48 ` Muchun Song
2026-10-02 8:22 ` Mike Rapoport
2026-10-02 9:56 ` Muchun Song [this message]
2026-10-02 18:12 ` Mike Rapoport
2026-10-01 16:09 ` Lance Yang
2026-09-29 21:32 ` [PATCH v3 0/6] mm: Unify device DAX and HugeTLB vmemmap population paths Andrew Morton
2026-09-30 1:26 ` Muchun Song
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=85941AA4-7E50-4AAE-BC05-0F443B21BE8B@linux.dev \
--to=muchun.song@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=chleroy@kernel.org \
--cc=david@kernel.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=ljs@kernel.org \
--cc=maddy@linux.ibm.com \
--cc=mhocko@suse.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=qi.zheng@linux.dev \
--cc=ritesh.list@gmail.com \
--cc=rppt@kernel.org \
--cc=songmuchun@bytedance.com \
--cc=sshegde@linux.ibm.com \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
/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
all inboxes | Powered by JetHome®