On 6/15/21 5:40 AM, Matthew Wilcox wrote: > On Tue, Jun 15, 2021 at 01:03:53PM +0200, Jann Horn wrote: >> The messier path, as the original commit describes, is "gigantic" page >> allocation. In that case, we'll go through the following path (if we >> ignore CMA): >> >> alloc_fresh_huge_page(): >> alloc_gigantic_page() >> alloc_contig_pages() >> __alloc_contig_pages() >> alloc_contig_range() >> isolate_freepages_range() >> split_map_pages() >> post_alloc_hook() [FOR EVERY PAGE] >> set_page_refcounted() >> set_page_count(page, 1) >> prep_compound_gigantic_page() >> set_page_count(p, 0) [FOR EVERY TAIL PAGE] >> >> so all the tail pages are initially allocated with refcount 1 by the >> page allocator, and then we overwrite those refcounts with zeroes. >> >> >> Luckily, the only non-__init codepath that can get here is >> __nr_hugepages_store_common(), which is only invoked from privileged >> writes to sysfs/sysctls. Thanks for spotting this Jann! > Argh. What if we passed __GFP_COMP into alloc_contig_pages()? > The current callers of alloc_contig_range() do not pass __GFP_COMP, > so it's no behaviour change for them, and __GFP_COMP implies this > kind of behaviour. I think that would imply _not_ calling > split_map_pages(), which implies not calling post_alloc_hook(), > which means we probably need to do a lot of the parts of > post_alloc_hook() in alloc_gigantic_page(). Yuck. That might work. We would need to do something 'like' split_map_pages to split the compound free pages in the allocated range. Then, stitch them together into one big compound page. We 'should' be able to call post_alloc_hook on the resulting big compound page. Of course, that is all theory without digging into the details. Note that in the general case alloc_contig_range/alloc_contig_pages can be called to request a non-power of two number of pages. In such cases __GFP_COMP would make little sense. -- Mike Kravetz
