Re: [PATCH 1/2] mm: thp: introduce thp_mmu_gather to pin tail pages during MMU gather

[Andrew Morton <akpm@linux-foundation.org>]

On Thu, 19 Nov 2015 14:00:51 +0100 Andrea Arcangeli <aarcange@redhat.com> wrote:

> This theoretical SMP race condition was found with source review. No
> real life app could be affected as the result of freeing memory while
> accessing it is either undefined or it's a workload the produces no
> information.
> 
> For something to go wrong because the SMP race condition triggered,
> it'd require a further tiny window within the SMP race condition
> window. So nothing bad is happening in practice even if the SMP race
> condition triggers. It's still better to apply the fix to have the
> math guarantee.
> 
> The fix just adds a thp_mmu_gather atomic_t counter to the THP pages,
> so split_huge_page can elevate the tail page count accordingly and
> leave the tail page freeing task to whoever elevated thp_mmu_gather.
> 

This is a pretty nasty patch :( We now have random page*'s with bit 0
set floating around in mmu_gather.__pages[].  It assumes/requires that
nobody uses those pages until they hit release_pages().  And the tlb
flushing code is pretty twisty, with various Kconfig and arch dependent
handlers.

Is there no nicer way?

> +/*
> + * free_trans_huge_page_list() is used to free the pages returned by
> + * trans_huge_page_release() (if still PageTransHuge()) in
> + * release_pages().
> + */

There is no function trans_huge_page_release().

> +extern void free_trans_huge_page_list(struct list_head *list);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>