On 1/26/21 6:10 PM, Jason Gunthorpe wrote:

On Tue, Jan 26, 2021 at 05:58:53PM -0800, Mike Kravetz wrote:

quoted

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@oracle.com (local)

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