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

[Andrea Arcangeli <aarcange@redhat.com>]

On Mon, Dec 07, 2015 at 03:00:53PM +0530, Aneesh Kumar K.V wrote:
> Andrea Arcangeli <aarcange@redhat.com> writes:
> 
> > 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.
> >
> 
> Will this be a problem after
> http://article.gmane.org/gmane.linux.kernel.mm/139631  
> "[PATCHv12 00/37] THP refcounting redesign" ?

The THP zero page SMP TLB flushing race (patch 2/2) is definitely
still needed even with the THP refcounting redesign applied (perhaps
it'll reject but the problem remains exactly the same).

The MMU gather part (patch 1/2) as far as I can tell it's still needed
too because split_huge_page bails out on gup pins only (which is the
primary difference, as previously split_huge_page was forbidden to
fail to guarantee a graceful fallback into the legacy code after a
split_huge_page_pmd, but that introduced the need of more complex
put_page for tail pages to deal with the gup tail pins). There are no
gup pins involved in this race and put_page may still free the tails
in __split_huge_page despite the MMU gather THP TLB flush may not have
run yet (there's even still the comment about it in __split_huge_page
confirming this, so unless that comment is also wrong the theoretical
SMP race fix is needed). The locking in the __split_huge_page with the
refcounting redesign applied still retains the lru_lock so it would
also still allow to fix the race for good, with the refcounting
redesign, in the same way. Kirill please correct me if I overlooked
something in your patchset.

Thanks,
Andrea

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