The quilt patch titled Subject: mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled has been removed from the -mm tree. Its filename was mm-memory-failure-fix-deadlock-when-hugetlb_optimize_vmemmap-is-enabled-v2.patch

This patch was dropped because it was folded into mm-memory-failure-fix-deadlock-when-hugetlb_optimize_vmemmap-is-enabled.patch

------------------------------------------------------ From: Miaohe Lin linmiaohe@huawei.com Subject: mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled Date: Fri, 12 Apr 2024 10:57:54 +0800

extend comment per Oscar

Link: https://lkml.kernel.org/r/20240412025754.1897615-1-linmiaohe@huawei.com Fixes: a6b40850c442 ("mm: hugetlb: replace hugetlb_free_vmemmap_enabled with a static_key") Signed-off-by: Miaohe Lin linmiaohe@huawei.com Acked-by: Oscar Salvador osalvador@suse.de Cc: stable@vger.kernel.org Cc: Naoya Horiguchi nao.horiguchi@gmail.com Signed-off-by: Andrew Morton akpm@linux-foundation.org ---

mm/memory-failure.c | 4 ++++ 1 file changed, 4 insertions(+)

--- a/mm/memory-failure.c~mm-memory-failure-fix-deadlock-when-hugetlb_optimize_vmemmap-is-enabled-v2 +++ a/mm/memory-failure.c @@ -159,6 +159,10 @@ static int __page_handle_poison(struct p * dissolve_free_huge_page() might hold cpu_hotplug_lock via static_key_slow_dec() * when hugetlb vmemmap optimization is enabled. This will break current lock * dependency chain and leads to deadlock. + * Disabling pcp before dissolving the page was a deterministic approach because + * we made sure that those pages cannot end up in any PCP list. Draining PCP lists + * expels those pages to the buddy system, but nothing guarantees that those pages + * do not get back to a PCP queue if we need to refill those. */ ret = dissolve_free_huge_page(page); if (!ret) { _

Patches currently in -mm which might be from linmiaohe@huawei.com are

mm-memory-failure-fix-deadlock-when-hugetlb_optimize_vmemmap-is-enabled.patch fork-defer-linking-file-vma-until-vma-is-fully-initialized.patch