On Thu, 8 Apr 2021 09:11:30 +0200 Oscar Salvador <osalva...@suse.de> wrote:
> But if It is going to be easier for Andrew, just pull them all out and I > will resend the whole series once this work goes in. I think so. I shall drop these: mmpage_alloc-bail-out-earlier-on-enomem-in-alloc_contig_migrate_range.patch mmcompaction-let-isolate_migratepages_rangeblock-return-error-codes.patch mmcompaction-let-isolate_migratepages_rangeblock-return-error-codes-fix.patch mm-make-alloc_contig_range-handle-free-hugetlb-pages.patch mm-make-alloc_contig_range-handle-in-use-hugetlb-pages.patch mmpage_alloc-drop-unnecessary-checks-from-pfn_range_valid_contig.patch and these: mm-cma-change-cma-mutex-to-irq-safe-spinlock.patch hugetlb-no-need-to-drop-hugetlb_lock-to-call-cma_release.patch hugetlb-add-per-hstate-mutex-to-synchronize-user-adjustments.patch hugetlb-create-remove_hugetlb_page-to-separate-functionality.patch hugetlb-call-update_and_free_page-without-hugetlb_lock.patch hugetlb-change-free_pool_huge_page-to-remove_pool_huge_page.patch hugetlb-make-free_huge_page-irq-safe.patch hugetlb-make-free_huge_page-irq-safe-fix.patch hugetlb-add-lockdep_assert_held-calls-for-hugetlb_lock.patch Along with notes-to-self that this: https://lkml.kernel.org/r/YGwnPCPaq1xKh/8...@hirez.programming.kicks-ass.net might need attention and that this: hugetlb-make-free_huge_page-irq-safe.patch might need updating.
