From: David Hildenbrand Date: Mon, 1 Sep 2025 15:03:22 +0000 (+0200) Subject: mm: stop making SPARSEMEM_VMEMMAP user-selectable X-Git-Url: https://www.infradead.org/git/?a=commitdiff_plain;h=5b6ca5c98cb13bcda06e211e32b429ce439349b9;p=users%2Fjedix%2Flinux-maple.git mm: stop making SPARSEMEM_VMEMMAP user-selectable Patch series "mm: remove nth_page()", v2. As discussed recently with Linus, nth_page() is just nasty and we would like to remove it. To recap, the reason we currently need nth_page() within a folio is because on some kernel configs (SPARSEMEM without SPARSEMEM_VMEMMAP), the memmap is allocated per memory section. While buddy allocations cannot cross memory section boundaries, hugetlb and dax folios can. So crossing a memory section means that "page++" could do the wrong thing. Instead, nth_page() on these problematic configs always goes from page->pfn, to the go from (++pfn)->page, which is rather nasty. Likely, many people have no idea when nth_page() is required and when it might be dropped. We refer to such problematic PFN ranges and "non-contiguous pages". If we only deal with "contiguous pages", there is not need for nth_page(). Besides that "obvious" folio case, we might end up using nth_page() within CMA allocations (again, could span memory sections), and in one corner case (kfence) when processing memblock allocations (again, could span memory sections). So let's handle all that, add sanity checks, and remove nth_page(). Patch #1 -> #5 : stop making SPARSEMEM_VMEMMAP user-selectable + cleanups Patch #6 -> #13 : disallow folios to have non-contiguous pages Patch #14 -> #20 : remove nth_page() usage within folios Patch #22 : disallow CMA allocations of non-contiguous pages Patch #23 -> #33 : sanity+check + remove nth_page() usage within SG entry Patch #34 : sanity-check + remove nth_page() usage in unpin_user_page_range_dirty_lock() Patch #35 : remove nth_page() in kfence Patch #36 : adjust stale comment regarding nth_page Patch #37 : mm: remove nth_page() A lot of this is inspired from the discussion at [1] between Linus, Jason and me, so cudos to them. This patch (of 37): In an ideal world, we wouldn't have to deal with SPARSEMEM without SPARSEMEM_VMEMMAP, but in particular for 32bit SPARSEMEM_VMEMMAP is considered too costly and consequently not supported. However, if an architecture does support SPARSEMEM with SPARSEMEM_VMEMMAP, let's forbid the user to disable VMEMMAP: just like we already do for arm64, s390 and x86. So if SPARSEMEM_VMEMMAP is supported, don't allow to use SPARSEMEM without SPARSEMEM_VMEMMAP. This implies that the option to not use SPARSEMEM_VMEMMAP will now be gone for loongarch, powerpc, riscv and sparc. All architectures only enable SPARSEMEM_VMEMMAP with 64bit support, so there should not really be a big downside to using the VMEMMAP (quite the contrary). This is a preparation for not supporting (1) folio sizes that exceed a single memory section (2) CMA allocations of non-contiguous page ranges in SPARSEMEM without SPARSEMEM_VMEMMAP configs, whereby we want to limit possible impact as much as possible (e.g., gigantic hugetlb page allocations suddenly fails). Link: https://lkml.kernel.org/r/20250901150359.867252-1-david@redhat.com Link: https://lkml.kernel.org/r/20250901150359.867252-2-david@redhat.com Link: https://lore.kernel.org/all/CAHk-=wiCYfNp4AJLBORU-c7ZyRBUp66W2-Et6cdQ4REx-GyQ_A@mail.gmail.com/T/#u [1] Signed-off-by: David Hildenbrand Acked-by: Zi Yan Acked-by: Mike Rapoport (Microsoft) Acked-by: SeongJae Park Reviewed-by: Wei Yang Reviewed-by: Lorenzo Stoakes Reviewed-by: Liam R. Howlett Cc: Huacai Chen Cc: WANG Xuerui Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Christophe Leroy Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Cc: Alexandre Ghiti Cc: "David S. Miller" Cc: Andreas Larsson Cc: Alexander Gordeev Cc: Alexander Potapenko Cc: Alexandru Elisei Cc: Alex Dubov Cc: Alex Willamson Cc: Bart van Assche Cc: Borislav Betkov Cc: Brendan Jackman Cc: Brett Creeley Cc: Catalin Marinas Cc: Christian Borntraeger Cc: Christoph Lameter (Ampere) Cc: Damien Le Maol Cc: Dave Airlie Cc: Dennis Zhou Cc: Dmitriy Vyukov Cc: Doug Gilbert Cc: Heiko Carstens Cc: Herbert Xu Cc: Ingo Molnar Cc: Inki Dae Cc: James Bottomley Cc: Jani Nikula Cc: Jason A. Donenfeld Cc: Jason Gunthorpe Cc: Jason Gunthorpe Cc: Jens Axboe Cc: Jesper Nilsson Cc: Johannes Weiner Cc: John Hubbard Cc: Jonas Lahtinen Cc: Kevin Tian Cc: Lars Persson Cc: Linus Torvalds Cc: Marco Elver Cc: "Martin K. Petersen" Cc: Maxim Levitky Cc: Michal Hocko Cc: Muchun Song Cc: Niklas Cassel Cc: Oscar Salvador Cc: Pavel Begunkov Cc: Peter Xu Cc: Robin Murohy Cc: Rodrigo Vivi Cc: Shameerali Kolothum Thodi Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Tejun Heo Cc: Thomas Bogendoerfer Cc: Thomas Gleinxer Cc: Tvrtko Ursulin Cc: Ulf Hansson Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: Will Deacon Cc: Yishai Hadas Signed-off-by: Andrew Morton --- diff --git a/mm/Kconfig b/mm/Kconfig index b971d35c43c3..d1ed839ca710 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -412,9 +412,8 @@ config SPARSEMEM_VMEMMAP_ENABLE bool config SPARSEMEM_VMEMMAP - bool "Sparse Memory virtual memmap" + def_bool y depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE - default y help SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimise pfn_to_page and page_to_pfn operations. This is the most