On Tue 25-04-23 09:27:23, Baolin Wang wrote: > > > On 4/25/2023 8:22 AM, Huang, Ying wrote: > > Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx> writes: [...] > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > > index 6457b64fe562..bd124390c79b 100644 > > > --- a/mm/page_alloc.c > > > +++ b/mm/page_alloc.c > > > @@ -1502,6 +1502,15 @@ void __free_pages_core(struct page *page, unsigned int order) > > > * interleaving within a single pageblock. It is therefore sufficient to check > > > * the first and last page of a pageblock and avoid checking each individual > > > * page in a pageblock. > > > + * > > > + * Note: the function may return non-NULL struct page even for a page block > > > + * which contains a memory hole (i.e. there is no physical memory for a subset > > > + * of the pfn range). For example, if the pageblock order is MAX_ORDER, which > > > + * will fall into 2 sub-sections, and the end pfn of the pageblock may be hole > > > + * even though the start pfn is online and valid. This should be safe most of > > > + * the time because struct pages are still zero pre-filled and pfn walkers > > > > I don't think the pfn is just zero-filled even it's a hole. Can you > > confirm that? In memmap_init() and memmap_init_zone_range(), > > init_unavailable_range() is called to initialize the struct page. > > Yes, what I mean is the page frames were initialized to zero firstly, and > some fields were initialized to default value. The "zero pre-filled" seems > confusing, may be change to "initialized"? Huang Ying is correct. Holes should have struct pages initialized and init_unavailable_range actually marks those pages reserved. Which is really good because they mean "do not touch unless this page is yours". For some reason I thought those struct pages are simply zero filled. I was clearly wrong. Maybe it would be good to reference init_unavailable_range in the comment so that it is easier to track the whole code path. Sorry about that! -- Michal Hocko SUSE Labs
