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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e3d322e4-57e6-61d0-23e7-11f96f87415d@google.com>
Date:   Sat, 12 Jun 2021 20:14:37 -0700 (PDT)
From:   Hugh Dickins <hughd@...gle.com>
To:     Matthew Wilcox <willy@...radead.org>
cc:     Hugh Dickins <hughd@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Zhang Yi <wetpzy@...il.com>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Darren Hart <dvhart@...radead.org>,
        Davidlohr Bueso <dave@...olabs.net>,
        Neel Natu <neelnatu@...gle.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm, futex: Fix shared futex pgoff on shmem huge page

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