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: <YMTdtRZG+7q8OtkK@casper.infradead.org>
Date:   Sat, 12 Jun 2021 17:15:49 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Hugh Dickins <hughd@...gle.com>
Cc:     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 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.

>  static inline pgoff_t page_to_pgoff(struct page *page)
>  {
> -	if (unlikely(PageHeadHuge(page)))
> -		return page->index << compound_order(page);
> -
> +	if (unlikely(PageHuge(page))) {
> +		extern pgoff_t hugetlb_basepage_index(struct page *page);
> +		return hugetlb_basepage_index(page);
> +	}
>  	return page_to_index(page);
>  }

Yes, this change absolutely makes sense.  It's just a landmine if it
returns the right answer for some tail pages but garbage for other
kinds of tail pages.

> --- 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