linux-kernel - Re: [BUG/REGRESSION] THP: broken page count after commit aa88b68c

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]

Date:	Thu, 2 Jun 2016 18:51:50 +0300
From:	"Kirill A. Shutemov" <kirill@...temov.name>
To:	Gerald Schaefer <gerald.schaefer@...ibm.com>
Cc:	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Mel Gorman <mgorman@...hsingularity.net>,
	Hugh Dickins <hughd@...gle.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Dave Hansen <dave.hansen@...el.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Christian Borntraeger <borntraeger@...ibm.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>
Subject: Re: [BUG/REGRESSION] THP: broken page count after commit aa88b68c

On Thu, Jun 02, 2016 at 05:21:41PM +0200, Gerald Schaefer wrote:
> Christian Borntraeger reported a kernel panic after corrupt page counts,
> and it turned out to be a regression introduced with commit aa88b68c
> "thp: keep huge zero page pinned until tlb flush", at least on s390.
> 
> put_huge_zero_page() was moved over from zap_huge_pmd() to release_pages(),
> and it was replaced by tlb_remove_page(). However, release_pages() might
> not always be triggered by (the arch-specific) tlb_remove_page().
> 
> On s390 we call free_page_and_swap_cache() from tlb_remove_page(), and not
> tlb_flush_mmu() -> free_pages_and_swap_cache() like the generic version,
> because we don't use the MMU-gather logic. Although both functions have very
> similar names, they are doing very unsimilar things, in particular
> free_page_xxx is just doing a put_page(), while free_pages_xxx calls
> release_pages().
> 
> This of course results in very harmful put_page()s on the huge zero page,
> on architectures where tlb_remove_page() is implemented in this way. It
> seems to affect only s390 and sh, but sh doesn't have THP support, so
> the problem (currently) probably only exists on s390.
> 
> The following quick hack fixed the issue:
> 
> diff --git a/mm/swap_state.c b/mm/swap_state.c
> index 0d457e7..c99463a 100644
> --- a/mm/swap_state.c
> +++ b/mm/swap_state.c
> @@ -252,7 +252,10 @@ static inline void free_swap_cache(struct page *page)
>  void free_page_and_swap_cache(struct page *page)
>  {
>  	free_swap_cache(page);
> -	put_page(page);
> +	if (is_huge_zero_page(page))
> +		put_huge_zero_page();
> +	else
> +		put_page(page);
>  }
>  
>  /*

The fix looks good to me.

> But of course there might be a better solution, and there still are some
> questions left:
> - Why does free_page_xxx() behave so differently from free_pages_xxx()?

I don't see it behave too deiferently. It just try to batch freeing to
lower locking overhead.

> - Would it be OK to implement free_page_xxx() by calling free_pages_xxx()
>   with nr = 1, similar to free_page() vs. free_pages()?
> - Would it be OK to replace the put_page() in free_page_xxx() with a call
>   to release_pages() with nr = 1?

release_pages() somewhat suboptimal for nr=1. I guess we can fix this with
shortcut to put_page() at start of release_page() if nr == 1.

> - Would it be better to fix this in the arch-specific tlb_remove_page(),
>   by calling free_pages_xxx() with nr = 1 instead of free_page_xxx()?
> 
> Regards,
> Gerald
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@...ck.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>

-- 
 Kirill A. Shutemov