[PATCH 0/2] sh: mm: fix hugetlb on SH-4

[PATCH 0/2] sh: mm: fix hugetlb on SH-4

[Karl Mehltretter]

Muchun Song noted in the review of the Arm hugetlb alignment fix [1]
that SuperH has the same arch_get_unmapped_area() gap. Reproducing it
in QEMU turned up a second, older bug that corrupts memory once the
mappings are aligned.

Patch 1 fixes the page size in hugetlb PTEs. pte_mkhuge() ORs the huge
size into the base page size bits, so 64 KiB huge pages over 4 KiB
pages are loaded into the TLB as 1 MiB pages. User writes then land in
unrelated kernel memory. This dates back to the start of git history.

Patch 2 aligns hugetlb mappings to the huge page size. Without it
mmap(MAP_HUGETLB) can return an address that is not aligned to the huge
page size, and process exit hits the BUG_ON() in
__unmap_hugepage_range(). This is a 6.13
regression.

Patch 1 goes first because patch 2 alone makes the corruption reachable
through a plain mmap(). Both are marked for stable.

Tested on QEMU r2d (SH7751R, rts7751r2dplus_defconfig plus HUGETLBFS
with 64 KiB huge pages, gcc 15.2) on top of fddfc3ec3179. A test init
maps two huge pages with the default and legacy layouts and with
MAP_FIXED, writes and reads back every 4 KiB, mprotect()s the mapping
read-only and back, and checks a COW write in a forked child:

  kernel          MAP_FIXED       default/legacy mmap
  base            memory corrupt  misaligned, BUG at mm/hugetlb.c:5215
  patch 1         pass            misaligned, BUG
  patches 1+2     pass            pass

SH-X2 (X2TLB) is only build tested (r7785rp_defconfig with 64 KiB huge
pages).

QEMU's SH-4 TLB emulation flushes only the first 4 KiB of a 64 KiB or
1 MiB entry when the entry is dropped [2]. Keep that in mind when
testing hugetlb on QEMU.

[1] https://lore.kernel.org/r/5AB6FE85-4CB9-41EF-A700-BC5E071F29F5@linux.dev
[2] https://gitlab.com/qemu-project/qemu/-/issues/4598

Karl Mehltretter (2):
  sh: mm: replace the page size bits in pte_mkhuge()
  sh: mm: align hugetlb mappings to the huge page size

 arch/sh/include/asm/pgtable_32.h |  7 +++++--
 arch/sh/mm/mmap.c                | 11 +++++++++--
 2 files changed, 14 insertions(+), 4 deletions(-)


base-commit: fddfc3ec31799a932bb92f1b8a84cb3d1f963be9
-- 
2.39.5 (Apple Git-154)

[PATCH 1/2] sh: mm: replace the page size bits in pte_mkhuge()

[Karl Mehltretter]

pte_mkhuge() ORs _PAGE_SZHUGE into a PTE that already carries the base
page size from _PAGE_FLAGS_HARD, which every PAGE_* protection
includes. The PTEL size field is an encoding, not a set of flags: on
SH-4 with 4 KiB pages and 64 KiB huge pages, _PAGE_SZ0 | _PAGE_SZ1
selects a 1 MiB page. Every hugetlb mapping is therefore loaded into
the UTLB as a 1 MiB page whose physical base is the huge page's address
rounded down to 1 MiB, so user accesses land in unrelated kernel
memory.

In a QEMU r2d guest, after touching a MAP_HUGETLB mapping at
0x30000000, QEMU's "info tlb" shows

  vpn=c0000 ppn=32e00 sz=3 size=1048576

and writing the two huge pages overwrites kernel data, for example
page tables ("bad pgd 5a5a5a5a" on munmap) or a struct file:

  Fault in unaligned fixup: 0000 [#1]
  PC is at file_tty_write.isra.0+0x24/0x220
  R1  : 5a5a5a5a

The SH-X2 extended size field has the same problem: a 4 KiB base page
(ESZ0) combined with 64 KiB huge pages (ESZ2) encodes 256 KiB. Only the
configurations whose huge size encoding happens to contain the base
encoding, such as 1 MiB over 4 KiB on SH-4, have worked.

Clear the size field before setting the huge page size. All hugetlb
PTE constructors, including huge_pte_modify() on mprotect() and the
fork/COW paths, go through arch_make_huge_pte() and so pte_mkhuge().
With this change the same entry is loaded as

  vpn=c0000 ppn=32e00 sz=2 size=65536

and the mappings read back correctly after mprotect() and fork()/COW.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
 arch/sh/include/asm/pgtable_32.h | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/sh/include/asm/pgtable_32.h b/arch/sh/include/asm/pgtable_32.h
index 5f51af18997b..1e6821a23eac 100644
--- a/arch/sh/include/asm/pgtable_32.h
+++ b/arch/sh/include/asm/pgtable_32.h
@@ -145,6 +145,8 @@ static inline unsigned long copy_ptea_attributes(unsigned long x)
 # elif defined(CONFIG_HUGETLB_PAGE_SIZE_64MB)
 #  define _PAGE_SZHUGE	(_PAGE_EXT_ESZ2 | _PAGE_EXT_ESZ3)
 # endif
+# define _PAGE_SZHUGE_MASK	(_PAGE_EXT_ESZ0 | _PAGE_EXT_ESZ1 | \
+				 _PAGE_EXT_ESZ2 | _PAGE_EXT_ESZ3)
 # define _PAGE_WIRED	(_PAGE_EXT(_PAGE_EXT_WIRED))
 #else
 # if defined(CONFIG_HUGETLB_PAGE_SIZE_64K)
@@ -152,6 +154,7 @@ static inline unsigned long copy_ptea_attributes(unsigned long x)
 # elif defined(CONFIG_HUGETLB_PAGE_SIZE_1MB)
 #  define _PAGE_SZHUGE	(_PAGE_SZ0 | _PAGE_SZ1)
 # endif
+# define _PAGE_SZHUGE_MASK	(_PAGE_SZ_MASK)
 # define _PAGE_WIRED	(0)
 #endif
 
@@ -359,11 +362,11 @@ static inline pte_t pte_##fn(pte_t pte) { pte.pte_##h op; return pte; }
  */
 PTE_BIT_FUNC(high, wrprotect, &= ~(_PAGE_EXT_USER_WRITE | _PAGE_EXT_KERN_WRITE));
 PTE_BIT_FUNC(high, mkwrite_novma, |= _PAGE_EXT_USER_WRITE | _PAGE_EXT_KERN_WRITE);
-PTE_BIT_FUNC(high, mkhuge, |= _PAGE_SZHUGE);
+PTE_BIT_FUNC(high, mkhuge, = (pte.pte_high & ~_PAGE_SZHUGE_MASK) | _PAGE_SZHUGE);
 #else
 PTE_BIT_FUNC(low, wrprotect, &= ~_PAGE_RW);
 PTE_BIT_FUNC(low, mkwrite_novma, |= _PAGE_RW);
-PTE_BIT_FUNC(low, mkhuge, |= _PAGE_SZHUGE);
+PTE_BIT_FUNC(low, mkhuge, = (pte.pte_low & ~_PAGE_SZHUGE_MASK) | _PAGE_SZHUGE);
 #endif
 
 PTE_BIT_FUNC(low, mkclean, &= ~_PAGE_DIRTY);

base-commit: fddfc3ec31799a932bb92f1b8a84cb3d1f963be9
-- 
2.39.5 (Apple Git-154)

[PATCH 2/2] sh: mm: align hugetlb mappings to the huge page size

[Karl Mehltretter]

mmap(MAP_HUGETLB) on SH4 can return an address which is not aligned to
the huge page size. In a QEMU r2d guest with 64 KiB huge pages, a
two-page mapping placed after a single 4 KiB mapping lands at
0x29558000, and process exit then hits the alignment check in
__unmap_hugepage_range():

  kernel BUG at mm/hugetlb.c:5215!
  Kernel BUG: 003e [#1]
  PC is at __unmap_hugepage_range+0x3a4/0x424
  PR is at __zap_vma_range+0xa28/0xa80

Commit 7bd3f1e1a9ae ("mm: make hugetlb mappings go through
mm_get_unmapped_area_vmflags") made hugetlb mappings use the
architecture's arch_get_unmapped_area(). The generic implementations
handle hugetlb alignment, but the SH implementations only account for
the cache-colouring constraint in shm_align_mask, so the mapping ends
up aligned to at most the D-cache alias size.

Set the alignment mask from the file's hstate for hugetlb mappings in
both SH implementations, as LoongArch did in commit 3109d5ff484b
("LoongArch: Set hugetlb mmap base address aligned with pmd size").
Huge-page alignment also satisfies the colouring constraint. SH only
uses the bottom-up layout today, but the top-down variant gets the same
change so the two stay in sync.

Fixes: 7bd3f1e1a9ae ("mm: make hugetlb mappings go through mm_get_unmapped_area_vmflags")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
 arch/sh/mm/mmap.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/sh/mm/mmap.c b/arch/sh/mm/mmap.c
index c442734d9b0c..4df807e0df36 100644
--- a/arch/sh/mm/mmap.c
+++ b/arch/sh/mm/mmap.c
@@ -7,6 +7,7 @@
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
  */
+#include <linux/hugetlb.h>
 #include <linux/io.h>
 #include <linux/mm.h>
 #include <linux/sched/mm.h>
@@ -92,7 +93,10 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr,
 	info.length = len;
 	info.low_limit = TASK_UNMAPPED_BASE;
 	info.high_limit = TASK_SIZE;
-	info.align_mask = do_colour_align ? (PAGE_MASK & shm_align_mask) : 0;
+	if (filp && is_file_hugepages(filp))
+		info.align_mask = huge_page_mask_align(filp);
+	else
+		info.align_mask = do_colour_align ? (PAGE_MASK & shm_align_mask) : 0;
 	info.align_offset = pgoff << PAGE_SHIFT;
 	return vm_unmapped_area(&info);
 }
@@ -142,7 +146,10 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
 	info.length = len;
 	info.low_limit = PAGE_SIZE;
 	info.high_limit = mm->mmap_base;
-	info.align_mask = do_colour_align ? (PAGE_MASK & shm_align_mask) : 0;
+	if (filp && is_file_hugepages(filp))
+		info.align_mask = huge_page_mask_align(filp);
+	else
+		info.align_mask = do_colour_align ? (PAGE_MASK & shm_align_mask) : 0;
 	info.align_offset = pgoff << PAGE_SHIFT;
 	addr = vm_unmapped_area(&info);
 
-- 
2.39.5 (Apple Git-154)

Re: [PATCH 0/2] sh: mm: fix hugetlb on SH-4

[John Paul Adrian Glaubitz]

Hi Karl,

On Sat, 2026-09-26 at 20:39 +0200, Karl Mehltretter wrote:
> Muchun Song noted in the review of the Arm hugetlb alignment fix [1]
> that SuperH has the same arch_get_unmapped_area() gap. Reproducing it
> in QEMU turned up a second, older bug that corrupts memory once the
> mappings are aligned.
> 
> Patch 1 fixes the page size in hugetlb PTEs. pte_mkhuge() ORs the huge
> size into the base page size bits, so 64 KiB huge pages over 4 KiB
> pages are loaded into the TLB as 1 MiB pages. User writes then land in
> unrelated kernel memory. This dates back to the start of git history.
> 
> Patch 2 aligns hugetlb mappings to the huge page size. Without it
> mmap(MAP_HUGETLB) can return an address that is not aligned to the huge
> page size, and process exit hits the BUG_ON() in
> __unmap_hugepage_range(). This is a 6.13
> regression.
> 
> Patch 1 goes first because patch 2 alone makes the corruption reachable
> through a plain mmap(). Both are marked for stable.
> 
> Tested on QEMU r2d (SH7751R, rts7751r2dplus_defconfig plus HUGETLBFS
> with 64 KiB huge pages, gcc 15.2) on top of fddfc3ec3179. A test init
> maps two huge pages with the default and legacy layouts and with
> MAP_FIXED, writes and reads back every 4 KiB, mprotect()s the mapping
> read-only and back, and checks a COW write in a forked child:
> 
>   kernel          MAP_FIXED       default/legacy mmap
>   base            memory corrupt  misaligned, BUG at mm/hugetlb.c:5215
>   patch 1         pass            misaligned, BUG
>   patches 1+2     pass            pass
> 
> SH-X2 (X2TLB) is only build tested (r7785rp_defconfig with 64 KiB huge
> pages).
> 
> QEMU's SH-4 TLB emulation flushes only the first 4 KiB of a 64 KiB or
> 1 MiB entry when the entry is dropped [2]. Keep that in mind when
> testing hugetlb on QEMU.
> 
> [1] https://lore.kernel.org/r/5AB6FE85-4CB9-41EF-A700-BC5E071F29F5@linux.dev
> [2] https://gitlab.com/qemu-project/qemu/-/issues/4598
> 
> Karl Mehltretter (2):
>   sh: mm: replace the page size bits in pte_mkhuge()
>   sh: mm: align hugetlb mappings to the huge page size
> 
>  arch/sh/include/asm/pgtable_32.h |  7 +++++--
>  arch/sh/mm/mmap.c                | 11 +++++++++--
>  2 files changed, 14 insertions(+), 4 deletions(-)

Thanks for the patch! This should definitely be tested on real hardware
and I think it's a good reason to test this on my SH7785LCR which wouldn't
boot on anything newer than 6.5.0.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH 0/2] sh: mm: fix hugetlb on SH-4

[Karl Mehltretter]

On Sat, Sep 26, 2026 at 08:43:45PM +0100, John Paul Adrian Glaubitz wrote:
> Thanks for the patch! This should definitely be tested on real hardware
> and I think it's a good reason to test this on my SH7785LCR which wouldn't
> boot on anything newer than 6.5.0.
> 

Hi Adrian,

Testing with real hardware is very cool! Maybe I will get some SH
hardware myself one day. For now you've motivated me to do a QEMU SuperH
fork with more features, with a lot of help from my LLM agent:

https://github.com/kmehltretter82/qemu-superh

I will send some bug fix patches based on it soon, hopefully also fixing
your 6.5 problem. I believe it is an old heap overflow in the SH intc
code that only started to crash when sh7785lcr_defconfig switched from
SLAB to SLUB in 6.5.

Karl

Re: [PATCH 0/2] sh: mm: fix hugetlb on SH-4

[John Paul Adrian Glaubitz]

Hi Karl,

On Sun, 2026-09-27 at 20:35 +0200, Karl Mehltretter wrote:
> On Sat, Sep 26, 2026 at 08:43:45PM +0100, John Paul Adrian Glaubitz wrote:
> > Thanks for the patch! This should definitely be tested on real hardware
> > and I think it's a good reason to test this on my SH7785LCR which wouldn't
> > boot on anything newer than 6.5.0.
> > 
> 
> Testing with real hardware is very cool! Maybe I will get some SH
> hardware myself one day. For now you've motivated me to do a QEMU SuperH
> fork with more features, with a lot of help from my LLM agent:
> 
> https://github.com/kmehltretter82/qemu-superh

Thanks, appreciate the patches. I'll try to look at these patches tomorrow.

Since I am reviewing them in detail, it can take me a few hours to properly
review them. Usually, I'm also asking Geert to have a look at them as well
since he is a far more experienced kernel developer than I am.

> I will send some bug fix patches based on it soon, hopefully also fixing
> your 6.5 problem. I believe it is an old heap overflow in the SH intc
> code that only started to crash when sh7785lcr_defconfig switched from
> SLAB to SLUB in 6.5.

Great, I'll give that patch a try tomorrow when I'm back home. Would be
great to unbreak my favorite SH board.

Btw, feel free to join us in #linux-sh on Libera IRC and/or on Discord:

https://discord.gg/WhtqXkYys

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913