Re: [PATCH] mm, futex: Fix shared futex pgoff on shmem huge page

[Hugh Dickins <hughd@google.com>]

On Sat, 12 Jun 2021, Matthew Wilcox wrote:
> On Fri, Jun 11, 2021 at 09:31:16PM -0700, Hugh Dickins wrote:
> > +++ linux/include/linux/pagemap.h	2021-06-11 17:30:28.726720252 -0700
> > @@ -516,8 +516,7 @@ static inline struct page *read_mapping_
> >  }
> >  
> >  /*
> > - * Get index of the page with in radix-tree
> > - * (TODO: remove once hugetlb pages will have ->index in PAGE_SIZE)
> > + * Get index of the page within radix-tree (but not for hugetlb pages).
> >   */
> 
> I think the TODO should be retained.  It's still something that I
> intend to do.

Okay.  I did not mean to imply, by removing those TODOs, that they
should not be done: just that they were a developer's notes to self,
that I found distracting there.

I've restored both TODOs (but changed the second to say
"hugetlb pages" explicitly, rather than the ambiguous "hugepage").

> > --- 5.13-rc5/mm/hugetlb.c	2021-06-06 16:57:26.263006733 -0700
> > +++ linux/mm/hugetlb.c	2021-06-11 17:30:28.730720276 -0700
> > @@ -1588,15 +1588,12 @@ struct address_space *hugetlb_page_mappi
> >  	return NULL;
> >  }
> >  
> > -pgoff_t __basepage_index(struct page *page)
> > +pgoff_t hugetlb_basepage_index(struct page *page)
> >  {
> >  	struct page *page_head = compound_head(page);
> >  	pgoff_t index = page_index(page_head);
> >  	unsigned long compound_idx;
> >  
> > -	if (!PageHuge(page_head))
> > -		return page_index(page);
> > -
> >  	if (compound_order(page_head) >= MAX_ORDER)
> >  		compound_idx = page_to_pfn(page) - page_to_pfn(page_head);
> >  	else
> > 
> 
> urgh.  this trailing bit should be:
> 
> #if defined(CONFIG_SPARSEMEM) && !defined(CONFIG_SPARSEMEM_VMEMMAP)
> 	compound_idx = page_to_pfn(page) - page_to_pfn(page_head);
> #else
> 	compound_idx = page - page_head;
> #endif

I don't see what's wrong with what's there, myself.  Unfamiliar territory
to me, but mem_map_next() appears to have the same MAX_ORDER expectation.
Or perhaps you're just suggesting an optimization.

If it were obvious to me, I'd have gladly folded it in; but no,
please send your own patch for that, running it by Mike Kravetz
and Mike Rapoport and David Hildenbrand, I think.

Thanks, v2 follows,
Hugh