[PATCH 0/8] Stop special-casing hugetlb mappings in get_unmapped_area

Oscar Salvador posted 8 patches 2 days, 1 hour ago
arch/loongarch/mm/mmap.c         |  6 +-----
arch/s390/mm/mmap.c              |  9 ++-------
arch/sparc/kernel/sys_sparc_32.c | 16 +++-------------
arch/sparc/kernel/sys_sparc_64.c | 25 ++++++-------------------
arch/x86/kernel/sys_x86_64.c     | 15 ++++-----------
fs/hugetlbfs/inode.c             | 25 ++++++++++++++++++++++++-
include/linux/hugetlb.h          | 10 ----------
mm/mmap.c                        |  4 ----
8 files changed, 40 insertions(+), 70 deletions(-)
[PATCH 0/8] Stop special-casing hugetlb mappings in get_unmapped_area
Posted by Oscar Salvador 2 days, 1 hour ago
A regression was reported on AMD 15h Family for hugetlb mappings when 'align_va_addr'
is set [1].
Historically, for hugetlb mappings we always ignored 'align_offset' in get_unmapped_area
functions, but after commit 7bd3f1e1a9ae ("mm: make hugetlb mappings go through
mm_get_unmapped_area_vmflags") that was no longer the case for x86.

While we could fix that by work it around in x86 code, the truth is that the current
functioning of hugetlb mappings with get_unmapped_area functions is a bit clumsy, and
we can do better.
This patchset aims at two things:

1) Fix regression reported in [1]
2) Stop special-casing hugetlb mappings in get_unmapped_area functions

Fixing the regression involve doing what we do for THP mappings, which is encoding
the extra padding we need for worst-case-alignment scenarios directly in the 'len'
parameter and stop using 'align_mask' for that matter.
And then, mask off the address we get from mm_get_unmapped_area_vmflags.

After that, since the set up of 'align_mask' for hugetlb mappings disappears, this
means we do not have to be hugetlb-aware down the road, and we can stop special casing
it.

The only thing to note though is that depending on the architecture, we sometimes
use 'align_mask' to do coloring for pagecache and to avoid cache aliasing.
This was ignored for hugetlb mappings, but after this patchset that is no longer the
case, so this means that 'align_mask' will be added on top of the requested length
of the mapping, making us to allocate a larger(ish) gap in the mapple tree, but
that should be harmless as most of the times that is PAGE_SIZE, and whatever
the offset is will be masked off in hugetlb_get_unmapped_area.

[NOTE]
Patch#1 is v2, since Dave Hansen was kind enough to provide some feedback
in [2] while this was still on the works.

[1] https://lore.kernel.org/linux-mm/20260527143643.GO31091@soohrt.org/
[2] https://lore.kernel.org/linux-mm/bae37c0c-f9e8-486b-a1a8-53c9dc0af8e0@intel.com/#t

Oscar Salvador (8):
  mm,hugetlb: Encode extra padding for aligning directly in
    hugetlb_get_unmapped_area
  mm/mmap: Stop special-casing hugetlb in generic_get_unmapped_area path
  arch/x86: Stop special-casing hugetlb mappings in
    arch_get_unmapped_area
  arch/s390: Stop special-casing hugetlb mappings in
    arch_get_unmapped_area
  arch/loongarch: Stop special-casing hugetlb in
    arch_get_unmapped_area_common
  arch/sparc64: Stop special-casing hugetlb mappings in
    arch_get_unmapped_area
  arch/sparc32: Rip out hugetlb from sys_sparc_32.c
  mm,hugetlb: Kill huge_page_mask_align

 arch/loongarch/mm/mmap.c         |  6 +-----
 arch/s390/mm/mmap.c              |  9 ++-------
 arch/sparc/kernel/sys_sparc_32.c | 16 +++-------------
 arch/sparc/kernel/sys_sparc_64.c | 25 ++++++-------------------
 arch/x86/kernel/sys_x86_64.c     | 15 ++++-----------
 fs/hugetlbfs/inode.c             | 25 ++++++++++++++++++++++++-
 include/linux/hugetlb.h          | 10 ----------
 mm/mmap.c                        |  4 ----
 8 files changed, 40 insertions(+), 70 deletions(-)

-- 
2.35.3