On Thu, 19 Nov 2015 14:00:51 +0100 Andrea Arcangeli <aarcange@xxxxxxxxxx> 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>