On 01/11/2016 06:20 PM, Andrew Morton wrote: > On Mon, 11 Jan 2016 17:36:43 -0800 Mike Kravetz <mike.kravetz@xxxxxxxxxx> wrote: > >>> >>> I'll mark this patch as "pending, awaiting Mike's go-ahead". >>> >> >> When this patch was originally submitted, bugs were discovered in the >> hugetlb_vmdelete_list routine. So, the patch "Fix bugs in >> hugetlb_vmtruncate_list" was created. >> >> I have retested the changes in this patch specifically dealing with >> page fault/hole punch race on top of the new hugetlb_vmtruncate_list >> routine. Everything looks good. >> >> How would you like to proceed with the patch? >> - Should I create a series with the hugetlb_vmtruncate_list split out? >> - Should I respin with hugetlb_vmtruncate_list patch applied? >> >> Just let me know what is easiest/best for you. > > If you're saying that > http://ozlabs.org/~akpm/mmots/broken-out/mm-mempolicy-skip-non-migratable-vmas-when-setting-mpol_mf_lazy.patch That should be, http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlbfs-fix-bugs-in-hugetlb_vmtruncate_list.patch > and > http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlbfs-unmap-pages-if-page-fault-raced-with-hole-punch.patch > are the final everything-works versions then we're all good to go now. > The only thing that 'might' be an issue is the new reference to hugetlb_vmdelete_list() from remove_inode_hugepages(). hugetlb_vmdelete_list() was after remove_inode_hugepages() in the source file. The original patch moved hugetlb_vmdelete_list() to satisfy the new reference. I can not tell if that was taken into account in the way the patches were pulled into your tree. Will certainly know when it comes time to build. -- Mike Kravetz -- 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>