On 1/26/21 6:10 PM, Jason Gunthorpe wrote: > On Tue, Jan 26, 2021 at 05:58:53PM -0800, Mike Kravetz wrote: > >> As pointed out by Joao, you can also see the differences in pfn_to_page >> for CONFIG_SPARSE_VMEMMAP and CONFIG_SPARSEMEM. The only time we might >> have issues is with CONFIG_SPARSEMEM. I would bet CONFIG_SPARSE_VMEMMAP >> is far more common. > > I think it is fine to have a different pfn_to_page, it should just be > illegal to combine pages into a compound if their tail pages are not > linear in the map. > > Matt's folio work might present an option to audit the whole mm for > this pattern and provide some folio_next_tail_page() accessor that > does the fast thing - but I question the value of such a project for a > 2008 era PPC platform with 16GB pages (seriously?) that may be using > VMEMMAP today anyhow?? > > Maybe others know of more modern use cases > > Jason When discussing v2 of this patch, Zi confirmed that this issue exists today. See, https://lore.kernel.org/linux-mm/3d2acb33-57e2-060d-616f-cce872c77307@xxxxxxxxxx I will fix up that unexpected discovery in the hugetlb code. But, not sure what approach we want to take elsewhere, such as the GUP code. -- Mike Kravetz
