On Fri, Oct 02, 2026 at 05:56:40PM +0800, Muchun Song wrote: > > On Oct 2, 2026, at 16:22, Mike Rapoport <[email protected]> wrote: > > >>>> 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?
While it feels really out of place in __init_single_page(), but having it memmap_init_range() close to the if that skips shared tail pages makes sense. What do you say? > [1] https://lore.kernel.org/[email protected]/ > > Thanks, > Muchun -- Sincerely yours, Mike.
