Andrea Arcangeli <aarcange@xxxxxxxxxx> 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" ? -aneesh -- 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>