[PATCH] mm: clear pmd in pmdp_invalidate()

[PATCH] mm: clear pmd in pmdp_invalidate()

[Guilherme Giacomo Simoes]

when attempt to do a madvise in a chunk of memory allocated by mmap, the
folio_split is called to split a portion of memory, and despite the path
leads to pmd_mkinvalid() they do not clear the pmd and clearer wording,
leading to a BUG_ON inside page_table_check_set() because the map count
is more than 1.

Call the page_table_check_pmd_clear() inside pmdp_invalidate() generic
function to ensure that the pmd will have they map count decrement.

Signed-off-by: Guilherme Giacomo Simoes <trintaeoitogc@gmail.com>
---
 mm/pgtable-generic.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c
index b91b1a98029c..7fa5351c75a0 100644
--- a/mm/pgtable-generic.c
+++ b/mm/pgtable-generic.c
@@ -203,6 +203,7 @@ pmd_t pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
 {
 	VM_WARN_ON_ONCE(!pmd_present(*pmdp));
 	pmd_t old = pmdp_establish(vma, address, pmdp, pmd_mkinvalid(*pmdp));
+	page_table_check_pmd_clear(vma->vm_mm, address, old);
 	flush_pmd_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
 	return old;
 }
-- 
2.52.0

Re: [PATCH] mm: clear pmd in pmdp_invalidate()

[David Hildenbrand (Arm)]

On 10/27/26 12:38, Guilherme Giacomo Simoes wrote:
> when attempt to do a madvise in a chunk of memory allocated by mmap, the
> folio_split is called to split a portion of memory, and despite the path
> leads to pmd_mkinvalid() they do not clear the pmd and clearer wording,
> leading to a BUG_ON inside page_table_check_set() because the map count
> is more than 1.
> 
> Call the page_table_check_pmd_clear() inside pmdp_invalidate() generic
> function to ensure that the pmd will have they map count decrement.
> 

The subject + description is rather confusing: you are not "clearing the pmd",
you tell page-table-check that the PMD was cleared.

This is all about apge-table-check.

Can you post the actual kernel splat you ran into? Or is this generated by an LLM?

Thanks!

-- 
Cheers,

David

Re: [PATCH] mm: clear pmd in pmdp_invalidate()

[Guilherme Giacomo Simoes]

"David Hildenbrand (Arm)" <david@kernel.org> wrote:
> > when attempt to do a madvise in a chunk of memory allocated by mmap, the
> > folio_split is called to split a portion of memory, and despite the path
> > leads to pmd_mkinvalid() they do not clear the pmd and clearer wording,
> > leading to a BUG_ON inside page_table_check_set() because the map count
> > is more than 1.
> > 
> > Call the page_table_check_pmd_clear() inside pmdp_invalidate() generic
> > function to ensure that the pmd will have they map count decrement.
> > 
> 
> The subject + description is rather confusing: you are not "clearing the pmd",
> you tell page-table-check that the PMD was cleared.
> 
> This is all about apge-table-check.
Yes, you are right, i'm not clearing the pmd, I will improve this.

> 
> Can you post the actual kernel splat you ran into? Or is this generated by an LLM?
Of course, the stack trace of error is (already decoded):
page_table_check_set (mm/page_table_check.c:118)
__page_table_check_ptes_set (mm/page_table_check.c:223)
remove_migration_pte (include/linux/page_table_check.h:83 arch/riscv/include/asm/pgtable.h:642 mm/migrate.c:448)
rmap_walk_anon (mm/rmap.c:3053)
rmap_walk_locked (mm/rmap.c:3169 mm/rmap.c:3164)
remove_migration_ptes (mm/migrate.c:483)
__folio_split (mm/huge_memory.c:3640 mm/huge_memory.c:4289)
split_folio_to_list (mm/huge_memory.c:4435 include/linux/huge_mm.h:416 mm/huge_memory.c:4499)
madvise_cold_or_pageout_pte_range (mm/madvise.c:420)
walk_pgd_range (mm/pagewalk.c:147 mm/pagewalk.c:237 mm/pagewalk.c:278 mm/pagewalk.c:319)
__walk_page_range (mm/pagewalk.c:427)
walk_page_range_vma_unsafe (mm/pagewalk.c:737)
walk_page_range_vma (mm/pagewalk.c:747)
madvise_cold (mm/madvise.c:594 mm/madvise.c:614)
madvise_vma_behavior (mm/madvise.c:1364)
madvise_walk_vmas (mm/madvise.c:1721)
madvise_do_behavior (mm/madvise.c:1916)
do_madvise (mm/madvise.c:2014)
__riscv_sys_madvise (mm/madvise.c:2023 mm/madvise.c:2021 mm/madvise.c:2021)
syscall_handler (arch/riscv/include/asm/syscall.h:112)
do_trap_ecall_u (arch/riscv/kernel/traps.c:341)
handle_exception (arch/riscv/kernel/entry.S:237)

And the repro.c that I writed to reproduce bug:
```
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/syscall.h>
#include <errno.h>
#include <linux/mman.h>

#ifndef MADV_COLD
#define MADV_COLD 20
#endif

#define HPAGE_PMD_SIZE (2 * 1024 * 1024)  // 2MB huge page on RISC-V

int main(void)
{
	char *addr;
	size_t len = HPAGE_PMD_SIZE * 2;  // 4MB - two huge pages
	int ret;

	printf("Testing page_table_check bug with madvise(MADV_COLD)...\n");
	printf("Huge page size: %zu MB\n", HPAGE_PMD_SIZE / (1024*1024));

	// Fallback: try without MAP_HUGETLB (kernel will use THP)
	printf("starting THP...\n");
	addr = mmap(NULL, len, PROT_READ | PROT_WRITE,
		    MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
	if (addr == MAP_FAILED) {
		perror("mmap failed");
		return 1;
	}
	// Enable THP for this mapping
	ret = madvise(addr, len, MADV_HUGEPAGE);
	if (ret) {
		perror("madvise(MADV_HUGEPAGE) failed");
		return 1;
	}

	printf("Allocated memory at %p\n", addr);

	// Write to the pages to ensure they're mapped
	memset(addr, 'A', len);
	memset(addr + HPAGE_PMD_SIZE, 'B', HPAGE_PMD_SIZE);

	// Touch pages to ensure huge page allocation
	for (size_t i = 0; i < len; i += HPAGE_PMD_SIZE) {
		addr[i] = 'X';
	}

	printf("Memory initialized, calling madvise(MADV_COLD) on partial range...\n");

	// Call madvise(MADV_COLD) on a partial range of the first huge page
	// This should trigger the huge page split and the bug
	ret = madvise(addr + 4096, HPAGE_PMD_SIZE - 8192, MADV_COLD);
	if (ret) {
		perror("madvise(MADV_COLD) failed");
		// Don't return - the kernel might have crashed
	}

	printf("madvise returned: %d (errno: %d)\n", ret, errno);

	// If we get here without kernel crash, the bug might be fixed
	// or the conditions weren't met
	printf("Test completed (if kernel didn't crash, bug may be fixed or not triggered)\n");

	munmap(addr, len);
	return 0;
}
```

I see this BUG here:
https://lore.kernel.org/all/69851c62.a00a0220.37c87e.002e.GAE@google.com/T/

Yes, I'd should mencioned "Reported-by: syzbot+227179d5a8a87e9df90d@syzkaller.appspotmail.com", my bad

Re: [PATCH] mm: clear pmd in pmdp_invalidate()

[Guilherme Giacomo Simoes]

Guilherme Giacomo Simoes <trintaeoitogc@gmail.com> wrote:
> "David Hildenbrand (Arm)" <david@kernel.org> wrote:
> > > when attempt to do a madvise in a chunk of memory allocated by mmap, the
> > > folio_split is called to split a portion of memory, and despite the path
> > > leads to pmd_mkinvalid() they do not clear the pmd and clearer wording,
> > > leading to a BUG_ON inside page_table_check_set() because the map count
> > > is more than 1.
> > >
> > > Call the page_table_check_pmd_clear() inside pmdp_invalidate() generic
> > > function to ensure that the pmd will have they map count decrement.
> > >
> >
> > The subject + description is rather confusing: you are not "clearing the pmd",
> > you tell page-table-check that the PMD was cleared.
> >
> > This is all about apge-table-check.
> Yes, you are right, i'm not clearing the pmd, I will improve this.
> 
> >
> > Can you post the actual kernel splat you ran into? Or is this generated by an LLM?
> Of course, the stack trace of error is (already decoded):
> page_table_check_set (mm/page_table_check.c:118)
> __page_table_check_ptes_set (mm/page_table_check.c:223)
> remove_migration_pte (include/linux/page_table_check.h:83 arch/riscv/include/asm/pgtable.h:642 mm/migrate.c:448)
> rmap_walk_anon (mm/rmap.c:3053)
> rmap_walk_locked (mm/rmap.c:3169 mm/rmap.c:3164)
> remove_migration_ptes (mm/migrate.c:483)
> __folio_split (mm/huge_memory.c:3640 mm/huge_memory.c:4289)
> split_folio_to_list (mm/huge_memory.c:4435 include/linux/huge_mm.h:416 mm/huge_memory.c:4499)
> madvise_cold_or_pageout_pte_range (mm/madvise.c:420)
> walk_pgd_range (mm/pagewalk.c:147 mm/pagewalk.c:237 mm/pagewalk.c:278 mm/pagewalk.c:319)
> __walk_page_range (mm/pagewalk.c:427)
> walk_page_range_vma_unsafe (mm/pagewalk.c:737)
> walk_page_range_vma (mm/pagewalk.c:747)
> madvise_cold (mm/madvise.c:594 mm/madvise.c:614)
> madvise_vma_behavior (mm/madvise.c:1364)
> madvise_walk_vmas (mm/madvise.c:1721)
> madvise_do_behavior (mm/madvise.c:1916)
> do_madvise (mm/madvise.c:2014)
> __riscv_sys_madvise (mm/madvise.c:2023 mm/madvise.c:2021 mm/madvise.c:2021)
> syscall_handler (arch/riscv/include/asm/syscall.h:112)
> do_trap_ecall_u (arch/riscv/kernel/traps.c:341)
> handle_exception (arch/riscv/kernel/entry.S:237)
> 
> And the repro.c that I writed to reproduce bug:
> ```
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <unistd.h>
> #include <sys/mman.h>
> #include <sys/syscall.h>
> #include <errno.h>
> #include <linux/mman.h>
> 
> #ifndef MADV_COLD
> #define MADV_COLD 20
> #endif
> 
> #define HPAGE_PMD_SIZE (2 * 1024 * 1024)  // 2MB huge page on RISC-V
> 
> int main(void)
> {
>         char *addr;
>         size_t len = HPAGE_PMD_SIZE * 2;  // 4MB - two huge pages
>         int ret;
> 
>         printf("Testing page_table_check bug with madvise(MADV_COLD)...\n");
>         printf("Huge page size: %zu MB\n", HPAGE_PMD_SIZE / (1024*1024));
> 
>         // Fallback: try without MAP_HUGETLB (kernel will use THP)
>         printf("starting THP...\n");
>         addr = mmap(NULL, len, PROT_READ | PROT_WRITE,
>                     MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
>         if (addr == MAP_FAILED) {
>                 perror("mmap failed");
>                 return 1;
>         }
>         // Enable THP for this mapping
>         ret = madvise(addr, len, MADV_HUGEPAGE);
>         if (ret) {
>                 perror("madvise(MADV_HUGEPAGE) failed");
>                 return 1;
>         }
> 
>         printf("Allocated memory at %p\n", addr);
> 
>         // Write to the pages to ensure they're mapped
>         memset(addr, 'A', len);
>         memset(addr + HPAGE_PMD_SIZE, 'B', HPAGE_PMD_SIZE);
> 
>         // Touch pages to ensure huge page allocation
>         for (size_t i = 0; i < len; i += HPAGE_PMD_SIZE) {
>                 addr[i] = 'X';
>         }
> 
>         printf("Memory initialized, calling madvise(MADV_COLD) on partial range...\n");
> 
>         // Call madvise(MADV_COLD) on a partial range of the first huge page
>         // This should trigger the huge page split and the bug
>         ret = madvise(addr + 4096, HPAGE_PMD_SIZE - 8192, MADV_COLD);
>         if (ret) {
>                 perror("madvise(MADV_COLD) failed");
>                 // Don't return - the kernel might have crashed
>         }
> 
>         printf("madvise returned: %d (errno: %d)\n", ret, errno);
> 
>         // If we get here without kernel crash, the bug might be fixed
>         // or the conditions weren't met
>         printf("Test completed (if kernel didn't crash, bug may be fixed or not triggered)\n");
> 
>         munmap(addr, len);
>         return 0;
> }
> ```
> 
> I see this BUG here:
> https://lore.kernel.org/all/69851c62.a00a0220.37c87e.002e.GAE@google.com/T/
> 
> Yes, I'd should mencioned "Reported-by: syzbot+227179d5a8a87e9df90d@syzkaller.appspotmail.com", my bad

At first, I suspected of pmd_user_accessible_pages() and I started analyze this
function. In a brief search I found a CVE that fix similar bug:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=21e5eca0ac9046da9918a919bc92b7b5a78d27e7
They do this:
```
-	return pmd_leaf(pmd) && (pmd_user(pmd) || pmd_user_exec(pmd));
+	return pmd_leaf(pmd) && !pmd_present_invalid(pmd) && (pmd_user(pmd) || pmd_user_exec(pmd));
```

but, inside riscv-dependent code (where this fix happen), the pmd_user_accessible_page() is:
```
static inline bool pmd_user_accessible_page(struct mm_struct *mm, unsigned long addr, pmd_t pmd)
{
	return pmd_leaf(pmd) && pmd_user(pmd);
}
```

and the pmd_leaf() do:
```
	return pmd_present(pmd) && (pmd_val(pmd) & _PAGE_LEAF);
```

and pmd_present, do:
```
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
	(pmd_val(pmd) & (_PAGE_PRESENT | _PAGE_PROT_NONE | _PAGE_LEAF))
#else
	(pmd_val(pmd) & (_PAGE_PRESENT | _PAGE_PROT_NONE));
```

So , the pmd_leaf() looks like good enough to check if the pmd is accessible to
page_table_check.

... Too , I suspected of PAGE_PROT_NONE, because the doc above they declaration say:
```
/*
 * _PAGE_PROT_NONE is set on not-present pages (and ignored by the hardware) to
 * distinguish them from swapped out pages
 */
```
And this lead me to think "if set a not-present pages, so maybe this not should
return true inside pmd_user_accessible_page".... 

So I check the `git log` to see when and why this is introduced. But how is
mentioned by git commit message:
```
commit e3613bb8afc2a9474c9214d65c8326c5ac02135e
Author: Stefan O'Rear <sorear2@gmail.com>
Date:   Sun Dec 16 13:03:36 2018 -0500

    riscv: Add pte bit to distinguish swap from invalid
    
    Previously, invalid PTEs and swap PTEs had the same binary
    representation, causing errors when attempting to unmap PROT_NONE
    mappings, including implicit unmap on exit.

    ...
```

So , they is introduced to distinguish between swap and invalid ptes.

So , I concluded that this is not the problem, but maybe the documentation is
not good enought about the PAGE_PROT_NONE flag.

And, after a lot of thoughts, I try to call page_table_check_pmd_clear() ,
inside pmdp_invalidate(). I attempt to do this because, I see any architecture
dependent pmdp_invalidate() calling this function and think that probably this
is the solution... 
I apply , test with my repro.c and , this WORK. 

I implement this inside generic pmdp_invalidate() because, in my mind this is a
generic problem and can happen in any architecture not inside riscv specific.


thanks,
guilherme

[syzbot ci] Re: mm: clear pmd in pmdp_invalidate()

[syzbot ci]

syzbot ci has tested the following series

[v1] mm: clear pmd in pmdp_invalidate()
https://lore.kernel.org/all/20261027113813.1332096-1-trintaeoitogc@gmail.com
* [PATCH] mm: clear pmd in pmdp_invalidate()

and found the following issue:
kernel BUG in page_table_check_clear

Full report is available here:
https://ci.syzbot.org/series/ea6c690b-0dbf-4e3e-8367-2b5092d2878d

***

kernel BUG in page_table_check_clear

tree:      mm-new
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm.git
base:      01146870c415f6ff70a469fb7ceb962a3f2c8c52
arch:      amd64
compiler:  Debian clang version 22.1.8 (1~deb13u4), Debian LLD 22.1.8
config:    https://ci.syzbot.org/builds/b4be77d2-e026-48a2-b906-ba8967ba2d37/config
syz repro: https://ci.syzbot.org/findings/8fa94c36-acda-4fe5-a760-1dea60977f77/syz_repro

------------[ cut here ]------------
kernel BUG at mm/page_table_check.c:83!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 5817 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:page_table_check_clear+0x4ec/0x500 mm/page_table_check.c:83
Code: 89 e7 e8 f7 1a f4 ff e9 bd fb ff ff e8 4d 37 83 ff 90 0f 0b e8 45 37 83 ff 90 0f 0b e8 3d 37 83 ff 90 0f 0b e8 35 37 83 ff 90 <0f> 0b e8 2d 37 83 ff 90 0f 0b 66 2e 0f 1f 84 00 00 00 00 00 90 90
RSP: 0018:ffffc900035eed50 EFLAGS: 00010293
RAX: ffffffff8244dd9b RBX: 0000000000000200 RCX: ffff88810d88bc00
RDX: 0000000000000000 RSI: 00000000ffffffff RDI: 0000000000000000
RBP: ffff888104dea000 R08: ffff888104dea04b R09: 1ffff110209bd409
R10: dffffc0000000000 R11: ffffed10209bd40a R12: 00000000ffffffff
R13: 0000000000000001 R14: ffff888104dea048 R15: 0000000000116200
FS:  00007f8b11ee36c0(0000) GS:ffff88818c4c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000000140 CR3: 0000000112c36000 CR4: 00000000000006f0
Call Trace:
 <TASK>
 page_table_check_pmd_clear include/linux/page_table_check.h:64 [inline]
 pmdp_invalidate+0x2fc/0x310 mm/pgtable-generic.c:206
 __split_huge_pmd_locked mm/huge_memory.c:3323 [inline]
 split_huge_pmd_locked+0x100a/0x2e50 mm/huge_memory.c:3476
 __split_huge_pmd+0x202/0x2e0 mm/huge_memory.c:3490
 zap_pmd_range mm/memory.c:2136 [inline]
 zap_pud_range mm/memory.c:2179 [inline]
 zap_p4d_range mm/memory.c:2200 [inline]
 __zap_vma_range+0xb85/0x4f80 mm/memory.c:2240
 zap_vma_range_batched+0x3e0/0x5b0 mm/memory.c:2351
 madvise_dontneed_single_vma mm/madvise.c:868 [inline]
 madvise_dontneed_free mm/madvise.c:959 [inline]
 madvise_vma_behavior+0x252b/0x41d0 mm/madvise.c:1370
 madvise_walk_vmas+0x924/0xb00 mm/madvise.c:1687
 madvise_do_behavior+0x385/0x540 mm/madvise.c:1916
 do_madvise+0x327/0x3a0 mm/madvise.c:2014
 __do_sys_madvise mm/madvise.c:2023 [inline]
 __se_sys_madvise mm/madvise.c:2021 [inline]
 __x64_sys_madvise+0xa6/0xc0 mm/madvise.c:2021
 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
 do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f8b10f9f559
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f8b11ee3028 EFLAGS: 00000246 ORIG_RAX: 000000000000001c
RAX: ffffffffffffffda RBX: 00007f8b11225fa0 RCX: 00007f8b10f9f559
RDX: 0000000000000004 RSI: 0000000000003000 RDI: 000020000015e000
RBP: 00007f8b11036b20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f8b11226038 R14: 00007f8b11225fa0 R15: 00007fff02a6aba8
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:page_table_check_clear+0x4ec/0x500 mm/page_table_check.c:83
Code: 89 e7 e8 f7 1a f4 ff e9 bd fb ff ff e8 4d 37 83 ff 90 0f 0b e8 45 37 83 ff 90 0f 0b e8 3d 37 83 ff 90 0f 0b e8 35 37 83 ff 90 <0f> 0b e8 2d 37 83 ff 90 0f 0b 66 2e 0f 1f 84 00 00 00 00 00 90 90
RSP: 0018:ffffc900035eed50 EFLAGS: 00010293
RAX: ffffffff8244dd9b RBX: 0000000000000200 RCX: ffff88810d88bc00
RDX: 0000000000000000 RSI: 00000000ffffffff RDI: 0000000000000000
RBP: ffff888104dea000 R08: ffff888104dea04b R09: 1ffff110209bd409
R10: dffffc0000000000 R11: ffffed10209bd40a R12: 00000000ffffffff
R13: 0000000000000001 R14: ffff888104dea048 R15: 0000000000116200
FS:  00007f8b11ee36c0(0000) GS:ffff88818c4c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000000140 CR3: 0000000112c36000 CR4: 00000000000006f0


***

If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
  Tested-by: syzbot@syzkaller.appspotmail.com

---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.

To test a fix for this bug, please reply with `#syz test`
(on a separate line) and attach the patch to the email.

Notes:
- The patch will be applied on top of the tested series (as an
  incremental fix).
- To test a new version of the whole series, please send it directly
  to syzbot@lists.linux.dev.
- Arguments like custom git repos and branches are not supported.