On Mon, Jan 10, 2022 at 12:29:58AM -0800, Christoph Hellwig wrote: > On Mon, Jan 10, 2022 at 04:23:44AM +0000, Matthew Wilcox (Oracle) wrote: > > Several functions in gup.c assume that a compound page has virtually > > contiguous page structs. This isn't true for SPARSEMEM configs unless > > SPARSEMEM_VMEMMAP is also set. Fix them by using nth_page() instead of > > plain pointer arithmetic. > > So is this an actualy bug that need a Fixes tag, or do all architectures > that support THP and sparsemem use SPARSEMEM_VMEMMAP? As far as I can tell (and I am by no means an expert in this area), this problem only affects pages of order MAX_ORDER or higher. That is, somebody using regular 2MB hugepages on x86 won't see a problem, whether they're using VMEMMAP or not. It only starts to become a problem for 1GB hugepages. Since THPs are (currently) only allocated from the page allocator, it's never a problem for THPs, only hugetlbfs. Correcting the places which can't see a 1GB page is just defense against copy-and-paste programming. So I'll defer to Mike -- does this ever affect real systems and thus warrant a backport? I know this doesn't affect UEK because we enable SPARSEMEM_VMEMMAP. > > + page = nth_page(head, (addr & (sz-1)) >> PAGE_SHIFT); > > Would be nice to fix the indeation for sz - 1 while you're at it. Done.
