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@xxxxxxxxx. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
--
Kirill A. Shutemov
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>