On Tue, Nov 10, 2026 at 11:24 AM Hao Ge <[email protected]> wrote: > > __vmap_pages_range_noflush() and friends can install some PTEs before > failing and leave them mapped, and the kernel callers do not agree on > who cleans them up. pcpu_map_pages() and kmsan_ioremap_page_range() > roll back what they mapped before the failure, while > vm_module_tags_populate() and the __GFP_NOFAIL retry loop in > __vmalloc_area_node() rely on the mapping functions cleaning up and > do not call anything like vunmap_range() themselves. When the same > range is mapped again, the attempt hits the leftovers and fails with > a warning in vmap_pages_pte_range(). A leftover huge pmd is worse. > During the retry, vmap_try_huge_pmd() calls pmd_free_pte_page() on > it, and the x86 implementation cannot tell a leaf entry from a page > table and frees the mapped page.
Please note that there is a new function called vmap_pages_range_batched() which should also unmap its incomplete mappings on failure. This function was introduced by a patch called "mm/vmalloc: map contiguous pages in batches for vmap() if possible" in mm-new. I think it should be handled by this series as well. checkpatch.pl also complains about "Reported-by: should be immediately followed by Closes" on some of the patches, which can be easily fixed. > > After discussing with Suren and Ulad [1], we move the rollback into > the mapping functions. A failed vmap leaves nothing mapped, and the > callers no longer clean up after it. > > Patch 1 is the KMSAN part. The shadow and the origin of a range are > mapped by two separate calls, so the rollback there has to cover > both. Patch 2 is its disabled-KMSAN counterpart. Patches 3 to 5 bug > out on an unaligned range at the entry of the three range walkers. > Patch 6 only flushes the cache once the mapping succeeded. Patch 7 > adds the rollback to __vmap_pages_range_noflush() and > vmap_page_range(). Patches 8 and 9 drop the powerpc and percpu > cleanups that are not needed anymore. > > Changes since v3: > - drop v3 patch 3. The clamp papered over the caller bug, a bad > range now BUG_ONs at the unmap entry > - drop v3 patch 4. The reworked walk (24bbe1c56f63a) propagates > the errors already > - drop v3 patch 6. The walk below checks the range already > - the map side checks moved from the pte level to the entries of > vmap_range_noflush() and the walk, and became BUG_ON, in line > with the unmap side > - rebase onto the walk rework, commit messages updated accordingly > > [1] https://lore.kernel.org/all/[email protected]/ > > v3 link: https://lore.kernel.org/all/[email protected]/ > v2 link: https://lore.kernel.org/all/[email protected]/ > v1 link: https://lore.kernel.org/all/[email protected]/ > > Hao Ge (9): > mm/kmsan: undo the shadow mapping when the origin mapping fails > mm/kmsan: skip vunmap_range_noflush when KMSAN is disabled > mm/vmalloc: BUG_ON() on an unaligned range in vmap_range_noflush() > mm/vmalloc: BUG_ON() on an unaligned range in > vmap_pages_range_noflush_walk() > mm/vmalloc: BUG_ON() on an unaligned range in __vunmap_range_noflush() > mm/vmalloc: only flush the cache after the vmap succeeded > mm/vmalloc: undo partial mappings inside the mapping functions > powerpc: drop redundant unmaps of failed vmap mappings > mm/percpu: stop unmapping the CPU that failed to map > > arch/powerpc/kernel/isa-bridge.c | 5 +-- > arch/powerpc/kernel/pci_64.c | 4 +- > include/linux/kmsan.h | 8 +++- > mm/kmsan/hooks.c | 21 ++++++--- > mm/kmsan/shadow.c | 9 +++- > mm/percpu-vm.c | 5 ++- > mm/vmalloc.c | 75 ++++++++++++++++++++++++-------- > mm/vmalloc.h | 6 ++- > 8 files changed, 94 insertions(+), 39 deletions(-) > > -- > 2.25.1
