Re: [PATCH RFC 10/35] mm/hugetlb: cleanup hugetlb_folio_init_tail_vmemmap()
David Hildenbrand <[email protected]>
| Newsgroups | com.zx2c4.lists.wireguard,dev.linux.lists.iommu,dev.linux.lists.virtualization,org.freedesktop.lists.dri-devel,org.freedesktop.lists.intel-gfx,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-riscv,org.kernel.vger.io-uring,org.kernel.vger.kvm,org.kernel.vger.linux-crypto,org.kernel.vger.linux-ide,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-mips,org.kernel.vger.linux-mmc,org.kernel.vger.linux-s390,org.kernel.vger.linux-scsi,org.kernel.vger.netdev,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On 23.08.25 10:59, Mike Rapoport wrote: > On Fri, Aug 22, 2025 at 08:24:31AM +0200, David Hildenbrand wrote: >> On 22.08.25 06:09, Mika Penttilä wrote: >>> >>> On 8/21/25 23:06, David Hildenbrand wrote: >>> >>>> All pages were already initialized and set to PageReserved() with a >>>> refcount of 1 by MM init code. >>> >>> Just to be sure, how is this working with MEMBLOCK_RSRV_NOINIT, where MM is supposed not to >>> initialize struct pages? >> >> Excellent point, I did not know about that one. >> >> Spotting that we don't do the same for the head page made me assume that >> it's just a misuse of __init_single_page(). >> >> But the nasty thing is that we use memblock_reserved_mark_noinit() to only >> mark the tail pages ... > > And even nastier thing is that when CONFIG_DEFERRED_STRUCT_PAGE_INIT is > disabled struct pages are initialized regardless of > memblock_reserved_mark_noinit(). > > I think this patch should go in before your updates: Shouldn't we fix this in memblock code? Hacking around that in the memblock_reserved_mark_noinit() user sound wrong -- and nothing in the doc of memblock_reserved_mark_noinit() spells that behavior out. -- Cheers David / dhildenb