From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794023618; b=349+QzEnc9ZZUwmqthUYmJSTYBReb7IivxgWe143Kdjpm4CoIXHLKCuTMGaO+sEUq9lT PEdXstZSChNhMA1godNPatMZ0/j+wYV62qo7nXR0b/kM4aJDHwywe8P05UdpuK8Z6WG/+ bHzUNrT1yFFkxLFJ3IRbBkq9EJ3K2yA+yLD2L1fILj75wKLs2w5AjXsFU/SyX7gM18nr9 NjicIKXJkA6yfYzspck42s1HyOQdw83zPqYbJQU6VF4+BXVtXaWhaEWc/xC7dEOYq11fr ggAwqeGJSL4eYB8pMydmt1tRnnjL8IOU5DTWxB0KarG/W4KX39BMIpr61uN07jxEObA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794023618; h=Received:DKIM-Signature:Date:To:From:Subject:Message-Id; bh=/xAqQBzrIakAeK5K1saayY1CZPMWeyom1RzOwRlsYAI=; b=GJslPqBswJuO9Th8Prq3jJ6jfP4Fsp5CG6OK7kVqoqqnIUCkbSsXr3ZML865z6an0+T2 JrDICsIkOm5yqzv8qmbDoovGhSoPgFIKrga5lJ0pm1iFBv8kM5bRNO8rhi8omRJWCr7Bx mEeNPO87zX9AJlLtg48yNJh52F0Rg/cCC+MvNsVhwbQR65WH4xi4dy5XvEaREc8NNjHzm z4qO65OSR3APGi8Xc5Muf1u6tK6Rd0/++QMM8dpYFpbYJ1MyV19sLPQ7gprTCXUjsxr+c qe2PNwUV7Py2ER9fACSrMR3Y62f9/fUFdA3cZI1Eu2EPYwImflF0h12YG7knTGHN/oQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linux-foundation.org header.i=@linux-foundation.org header.a=rsa-sha256 header.s=korg header.b=iOw0DYWf; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 14839606A326 for ; Sat, 7 Nov 2026 03:53:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.a=rsa-sha256 header.s=korg header.b=iOw0DYWf Received: by smtp.kernel.org (Postfix) with ESMTPSA id 915FA1F0089F; Sat, 7 Nov 2026 03:53:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1794023617; bh=/xAqQBzrIakAeK5K1saayY1CZPMWeyom1RzOwRlsYAI=; h=Date:To:From:Subject; b=iOw0DYWfL2oVto/17iOJeuBc2anW4HTq06yJTRQyDindHSxuJezpdaVWZJq+c/Tf7 L2kQ56tpwI+PJT//bH9kyezSvReEHR8qty6Caa5cbuDMdEWaMb2E29HpX+EW0HoqdD 5Kkcb8XYvhsCKMhxVvZR4GfN7lTOAhG4wUmQpNsw= Date: Fri, 06 Nov 2026 19:53:37 -0800 To: mm-commits@vger.kernel.org,muchun.song@linux.dev,akpm@linux-foundation.org From: Andrew Morton Subject: + mm-hugetlb_vmemmap-unify-vmemmap_splitremap_no_tlb_flush.patch added to mm-unstable branch Message-Id: <20261107035337.915FA1F0089F@smtp.kernel.org> X-Mailing-List: mm-commits@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list The patch titled Subject: mm: hugetlb_vmemmap: unify VMEMMAP_{SPLIT,REMAP}_NO_TLB_FLUSH has been added to the -mm mm-unstable branch. Its filename is mm-hugetlb_vmemmap-unify-vmemmap_splitremap_no_tlb_flush.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-hugetlb_vmemmap-unify-vmemmap_splitremap_no_tlb_flush.patch This patch will later appear in the mm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: Muchun Song Subject: mm: hugetlb_vmemmap: unify VMEMMAP_{SPLIT,REMAP}_NO_TLB_FLUSH Date: Sat, 07 Nov 2026 10:27:46 +0800 VMEMMAP_SPLIT_NO_TLB_FLUSH and VMEMMAP_REMAP_NO_TLB_FLUSH do not describe fully independent choices. A split-only walk can defer the PMD-split flush to a later global flush, and a remap-only walk can defer the final remap flush. However, when a PMD split is followed by PTE remapping, the split flush must happen before the PTEs are changed, because stale large-page translations must not overlap with new small-page translations that map different physical pages. Replace the two flags with a single VMEMMAP_DEFER_TLB_FLUSH flag. The new name reflects that only safely batchable flushes are deferred. Keep split-only walks able to defer the flush, but force the split flush whenever a remap_pte callback is present. Callers that batch HVO work can still defer the final remap flush and issue their own global flush. Current callers keep the same flushing behavior. Link: https://lore.kernel.org/20261107022756.77731-4-songmuchun@bytedance.com Signed-off-by: Muchun Song Signed-off-by: Andrew Morton Reviewed-by: Lance Yang Reviewed-by: Qi Zheng Reviewed-by: Oscar Salvador Reviewed-by: Mike Rapoport (Microsoft) Tested-by: Andrew Morton Cc: James Houghton Cc: David Hildenbrand Cc: Yili Zhang Cc: Kiryl Shutsemau Cc: "Oscar Salvador (SUSE)" Cc: Huacai Chen --- mm/hugetlb_vmemmap.c | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) --- a/mm/hugetlb_vmemmap.c~mm-hugetlb_vmemmap-unify-vmemmap_splitremap_no_tlb_flush +++ a/mm/hugetlb_vmemmap.c @@ -42,10 +42,8 @@ struct vmemmap_remap_walk { struct list_head *vmemmap_pages; -/* Skip the TLB flush when we split the PMD */ -#define VMEMMAP_SPLIT_NO_TLB_FLUSH BIT(0) -/* Skip the TLB flush when we remap the PTE */ -#define VMEMMAP_REMAP_NO_TLB_FLUSH BIT(1) +/* Defer safely batchable TLB flushes to the caller. */ +#define VMEMMAP_DEFER_TLB_FLUSH BIT(0) unsigned long flags; }; @@ -85,7 +83,12 @@ static int vmemmap_split_pmd(pmd_t *pmd, /* Make pte visible before pmd. See comment in pmd_install(). */ smp_wmb(); pmd_populate_kernel(&init_mm, pmd, pgtable); - if (!(walk->flags & VMEMMAP_SPLIT_NO_TLB_FLUSH)) + /* + * Modern MMUs allow overlapping TLB entries with different mapping + * granularities only if they map the same physical address. So + * remapping must not proceed without first flushing the TLB. + */ + if (walk->remap_pte || !(walk->flags & VMEMMAP_DEFER_TLB_FLUSH)) flush_tlb_kernel_range(start, start + PMD_SIZE); } else { pte_free_kernel(&init_mm, pgtable); @@ -166,7 +169,7 @@ static int vmemmap_remap_range(unsigned if (ret) return ret; - if (walk->remap_pte && !(walk->flags & VMEMMAP_REMAP_NO_TLB_FLUSH)) + if (walk->remap_pte && !(walk->flags & VMEMMAP_DEFER_TLB_FLUSH)) flush_tlb_kernel_range(start, end); return 0; @@ -274,7 +277,7 @@ static int vmemmap_remap_split(unsigned { struct vmemmap_remap_walk walk = { .remap_pte = NULL, - .flags = VMEMMAP_SPLIT_NO_TLB_FLUSH, + .flags = VMEMMAP_DEFER_TLB_FLUSH, }; return vmemmap_remap_range(start, end, &walk); @@ -458,7 +461,7 @@ long hugetlb_vmemmap_restore_folios(cons struct folio *folio, *t_folio; long restored = 0; long ret = 0; - unsigned long flags = VMEMMAP_REMAP_NO_TLB_FLUSH; + unsigned long flags = VMEMMAP_DEFER_TLB_FLUSH; list_for_each_entry_safe(folio, t_folio, folio_list, lru) { if (folio_test_hugetlb_vmemmap_optimized(folio)) { @@ -517,7 +520,7 @@ static int __hugetlb_vmemmap_optimize_fo /* * Very Subtle - * If VMEMMAP_REMAP_NO_TLB_FLUSH is set, TLB flushing is not performed + * If VMEMMAP_DEFER_TLB_FLUSH is set, TLB flushing is not performed * immediately after remapping. As a result, subsequent accesses * and modifications to struct pages associated with the hugetlb * page could be to the OLD struct pages. Set the vmemmap optimized @@ -596,7 +599,7 @@ void hugetlb_vmemmap_optimize_folios(str struct folio *folio; unsigned long nr_to_optimize = 0; LIST_HEAD(vmemmap_pages); - unsigned long flags = VMEMMAP_REMAP_NO_TLB_FLUSH; + unsigned long flags = VMEMMAP_DEFER_TLB_FLUSH; if (list_empty(folio_list)) return; _ Patches currently in -mm which might be from muchun.song@linux.dev are mm-fix-missing-page-table-destructor-in-pagetable_free.patch riscv-mm-fix-hotplug-page-table-destructor-handling.patch riscv-mm-fix-missing-destructor-for-hotplug-pud-tables.patch arm64-mm-fix-destructor-for-unconstructed-hotplug-page-tables.patch mm-sparse-vmemmap-map-shared-vmemmap-tail-pages-as-read-only.patch powerpc-mm-map-shared-vmemmap-tail-pages-as-read-only.patch mm-hugetlb_vmemmap-remove-vmemmap_wrprotect_hvo.patch mm-hugetlb_vmemmap-remove-hugetlb_vmemmap_optimize_bootmem_folios.patch mm-generalize-kernel-pte-table-allocation.patch mm-generalize-pmd-page-table-allocation.patch mm-generalize-pud-page-table-allocation.patch mm-remove-pagetable_dtor_free.patch mm-remove-redundant-pagetable_dtor-calls.patch mm-hugetlb_vmemmap-remove-hugetlb-specific-vmemmap-optimization-macros.patch mm-hugetlb_vmemmap-unify-vmemmap_splitremap_no_tlb_flush.patch mm-hugetlb_vmemmap-simplify-vmemmap-head-page-handling.patch mm-hugetlb_vmemmap-generalize-vmemmap-page-allocation.patch mm-hugetlb_vmemmap-unify-writable-vmemmap-page-preparation.patch mm-hugetlb_vmemmap-rename-vmemmap_remap_pte-to-vmemmap_optimize_pte.patch mm-hugetlb_vmemmap-simplify-shared-tail-page-handling.patch mm-hugetlb_vmemmap-move-alloc_vmemmap_page_list-next-to-its-free-helper.patch mm-hugetlb_vmemmap-make-vmemmap-optimization-folio-oriented.patch mm-hugetlb_vmemmap-make-vmemmap-restoration-folio-oriented.patch mm-hugetlb_vmemmap-unify-vmemmap-range-restoration.patch mm-hugetlb_vmemmap-make-vmemmap-pte-conversion-folio-oriented.patch mm-hugetlb-fix-validation-of-unsupported-hugetlb-orders.patch