[syzbot] [mm?] WARNING in follow_page_pte

[syzbot] [mm?] WARNING in follow_page_pte

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    7e161a991ea7 Merge tag 'i2c-for-6.17-rc1-part2' of git://g..
git tree:       upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=16d385bc580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=75e522434dc68cb9
dashboard link: https://syzkaller.appspot.com/bug?extid=57bcc752f0df8bb1365c
compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13fa96a2580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1083c434580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/85ce789ac77a/disk-7e161a99.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/4d1fd8fed61a/vmlinux-7e161a99.xz
kernel image: https://storage.googleapis.com/syzbot-assets/9bd5f709ed6f/bzImage-7e161a99.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+57bcc752f0df8bb1365c@syzkaller.appspotmail.com

 do_initcall_level+0x104/0x190 init/main.c:1331
 do_initcalls+0x59/0xa0 init/main.c:1347
 kernel_init_freeable+0x334/0x4b0 init/main.c:1579
 kernel_init+0x1d/0x1d0 init/main.c:1469
 ret_from_fork+0x3f9/0x770 arch/x86/kernel/process.c:148
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
------------[ cut here ]------------
WARNING: CPU: 0 PID: 5866 at mm/gup.c:869 follow_page_pte+0xe3c/0x13e0 mm/gup.c:868
Modules linked in:
CPU: 0 UID: 0 PID: 5866 Comm: syz-executor302 Not tainted 6.16.0-syzkaller-11699-g7e161a991ea7 #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
RIP: 0010:follow_page_pte+0xe3c/0x13e0 mm/gup.c:868
Code: ff e8 f8 7a b7 ff 48 ff cb e9 a2 fc ff ff e8 eb 7a b7 ff 4c 89 f7 48 c7 c6 c0 11 96 8b e8 5c cb 1f ff c6 05 75 f7 84 0d 01 90 <0f> 0b 90 e9 0c fd ff ff e8 d7 46 70 09 89 d9 80 e1 07 80 c1 03 38
RSP: 0018:ffffc90003ddf8a0 EFLAGS: 00010246
RAX: 308c9254a9bba300 RBX: 0000000000000000 RCX: 308c9254a9bba300
RDX: 0000000000000004 RSI: ffffffff8dba2d77 RDI: ffff8880322c9e00
RBP: ffffc90003ddf988 R08: 0000000000000003 R09: 0000000000000004
R10: dffffc0000000000 R11: fffffbfff1bfa1ec R12: dffffc0000000000
R13: 0000000000080101 R14: ffffea0001c20240 R15: 0000000070809867
FS:  0000555557f15380(0000) GS:ffff888125c24000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000004340 CR3: 0000000072ff4000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 follow_pmd_mask mm/gup.c:-1 [inline]
 follow_pud_mask mm/gup.c:981 [inline]
 follow_p4d_mask mm/gup.c:998 [inline]
 follow_page_mask mm/gup.c:1041 [inline]
 __get_user_pages+0xa8e/0x2ce0 mm/gup.c:1444
 __get_user_pages_locked mm/gup.c:1712 [inline]
 __gup_longterm_locked+0x3dc/0x1660 mm/gup.c:2493
 pin_user_pages+0x9e/0xd0 mm/gup.c:3406
 xdp_umem_pin_pages+0x117/0x340 net/xdp/xdp_umem.c:105
 xdp_umem_reg net/xdp/xdp_umem.c:230 [inline]
 xdp_umem_create+0x677/0x8e0 net/xdp/xdp_umem.c:263
 xsk_setsockopt+0x7b0/0x8d0 net/xdp/xsk.c:1409
 do_sock_setsockopt+0x179/0x1b0 net/socket.c:2344
 __sys_setsockopt net/socket.c:2369 [inline]
 __do_sys_setsockopt net/socket.c:2375 [inline]
 __se_sys_setsockopt net/socket.c:2372 [inline]
 __x64_sys_setsockopt+0x13f/0x1b0 net/socket.c:2372
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f9ea1cc05b9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc94f86308 EFLAGS: 00000206 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9ea1cc05b9
RDX: 0000000000000004 RSI: 000000000000011b RDI: 0000000000000004
RBP: 00007f9ea1d335f0 R08: 000000000000001c R09: 0000000000000006
R10: 00002000000000c0 R11: 0000000000000206 R12: 0000000000000001
R13: 431bde82d7b634db R14: 0000000000000001 R15: 0000000000000001
 </TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [mm?] WARNING in follow_page_pte

[David Hildenbrand]

On 06.08.25 09:32, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    7e161a991ea7 Merge tag 'i2c-for-6.17-rc1-part2' of git://g..
> git tree:       upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=16d385bc580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=75e522434dc68cb9
> dashboard link: https://syzkaller.appspot.com/bug?extid=57bcc752f0df8bb1365c
> compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13fa96a2580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1083c434580000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/85ce789ac77a/disk-7e161a99.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/4d1fd8fed61a/vmlinux-7e161a99.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/9bd5f709ed6f/bzImage-7e161a99.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+57bcc752f0df8bb1365c@syzkaller.appspotmail.com
> 
>   do_initcall_level+0x104/0x190 init/main.c:1331
>   do_initcalls+0x59/0xa0 init/main.c:1347
>   kernel_init_freeable+0x334/0x4b0 init/main.c:1579
>   kernel_init+0x1d/0x1d0 init/main.c:1469
>   ret_from_fork+0x3f9/0x770 arch/x86/kernel/process.c:148
>   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 5866 at mm/gup.c:869 follow_page_pte+0xe3c/0x13e0 mm/gup.c:868

That's the

	VM_WARN_ON_ONCE_PAGE((flags & FOLL_PIN) && PageAnon(page) &&
			     !PageAnonExclusive(page), page);

[   89.134725][ T5866] page: refcount:507 mapcount:1 mapping:0000000000000000 index:0x200000009 pfn:0x70809
[   89.144633][ T5866] head: order:9 mapcount:505 entire_mapcount:0 nr_pages_mapped:505 pincount:2
[   89.153655][ T5866] memcg:ffff88801b6f8000
[   89.157938][ T5866] anon flags: 0xfff6000002007c(referenced|uptodate|dirty|lru|head|swapbacked|node=0|zone=1|lastcpupid=0x7ff)
[   89.170337][ T5866] raw: 00fff00000000000 ffffea0001c20001 dead000000000122 dead000000000400
[   89.179013][ T5866] raw: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[   89.188218][ T5866] head: 00fff6000002007c ffffea0001c52088 ffffea0001cc9988 ffff88807c250551
[   89.196996][ T5866] head: 0000000200000000 0000000000000000 000001fbffffffff ffff88801b6f8000
[   89.205866][ T5866] head: 00fff00000010a09 ffffea0001c20001 000001f9000001f8 00000002ffffffff
[   89.214719][ T5866] head: ffffffff000001f8 0000000000000015 0000000000000000 0000000000000200

So it's a pte-mapped THP, whereby the folio is pinned two times.

The warning indicates that we likely have !exclusive anon page that is mapped writable
into the page table.

xdp_umem_pin_pages calls pin_user_pages(FOLL_WRITE | FOLL_LONGTERM).

Let me dig, the reproducer seems to involve fork, io_uring, mprotect and setsockopt.

-- 
Cheers,

David / dhildenb

Re: [syzbot] [mm?] WARNING in follow_page_pte

[David Hildenbrand]

On 06.08.25 09:55, David Hildenbrand wrote:
> On 06.08.25 09:32, syzbot wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit:    7e161a991ea7 Merge tag 'i2c-for-6.17-rc1-part2' of git://g..
>> git tree:       upstream
>> console+strace: https://syzkaller.appspot.com/x/log.txt?x=16d385bc580000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=75e522434dc68cb9
>> dashboard link: https://syzkaller.appspot.com/bug?extid=57bcc752f0df8bb1365c
>> compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13fa96a2580000
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1083c434580000
>>
>> Downloadable assets:
>> disk image: https://storage.googleapis.com/syzbot-assets/85ce789ac77a/disk-7e161a99.raw.xz
>> vmlinux: https://storage.googleapis.com/syzbot-assets/4d1fd8fed61a/vmlinux-7e161a99.xz
>> kernel image: https://storage.googleapis.com/syzbot-assets/9bd5f709ed6f/bzImage-7e161a99.xz
>>
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: syzbot+57bcc752f0df8bb1365c@syzkaller.appspotmail.com
>>
>>    do_initcall_level+0x104/0x190 init/main.c:1331
>>    do_initcalls+0x59/0xa0 init/main.c:1347
>>    kernel_init_freeable+0x334/0x4b0 init/main.c:1579
>>    kernel_init+0x1d/0x1d0 init/main.c:1469
>>    ret_from_fork+0x3f9/0x770 arch/x86/kernel/process.c:148
>>    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
>> ------------[ cut here ]------------
>> WARNING: CPU: 0 PID: 5866 at mm/gup.c:869 follow_page_pte+0xe3c/0x13e0 mm/gup.c:868
> 
> That's the
> 
> 	VM_WARN_ON_ONCE_PAGE((flags & FOLL_PIN) && PageAnon(page) &&
> 			     !PageAnonExclusive(page), page);
> 
> [   89.134725][ T5866] page: refcount:507 mapcount:1 mapping:0000000000000000 index:0x200000009 pfn:0x70809
> [   89.144633][ T5866] head: order:9 mapcount:505 entire_mapcount:0 nr_pages_mapped:505 pincount:2
> [   89.153655][ T5866] memcg:ffff88801b6f8000
> [   89.157938][ T5866] anon flags: 0xfff6000002007c(referenced|uptodate|dirty|lru|head|swapbacked|node=0|zone=1|lastcpupid=0x7ff)
> [   89.170337][ T5866] raw: 00fff00000000000 ffffea0001c20001 dead000000000122 dead000000000400
> [   89.179013][ T5866] raw: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [   89.188218][ T5866] head: 00fff6000002007c ffffea0001c52088 ffffea0001cc9988 ffff88807c250551
> [   89.196996][ T5866] head: 0000000200000000 0000000000000000 000001fbffffffff ffff88801b6f8000
> [   89.205866][ T5866] head: 00fff00000010a09 ffffea0001c20001 000001f9000001f8 00000002ffffffff
> [   89.214719][ T5866] head: ffffffff000001f8 0000000000000015 0000000000000000 0000000000000200
> 
> So it's a pte-mapped THP, whereby the folio is pinned two times.
> 
> The warning indicates that we likely have !exclusive anon page that is mapped writable
> into the page table.
> 
> xdp_umem_pin_pages calls pin_user_pages(FOLL_WRITE | FOLL_LONGTERM).
> 
> Let me dig, the reproducer seems to involve fork, io_uring, mprotect and setsockopt.

Just tried on 6.16 and wasn't able to quickly reproduce.

I suspect that this is due to

commit cac1db8c3aad97d6ffb56ced8868d6cbbbd2bfbe
Author: Dev Jain <dev.jain@arm.com>
Date:   Fri Jul 18 14:32:43 2025 +0530

     mm: optimize mprotect() by PTE batching

whereby the

   syscall(__NR_mprotect, /*addr=*/0x200000000000ul, /*len=*/0x800000ul,
           /*prot=PROT_WRITE|PROT_EXEC*/ 6ul);

End sup upgrading write permissions and we somehow end up ignoring the 
missing PAE bit.

-- 
Cheers,

David / dhildenb

Re: [syzbot] [mm?] WARNING in follow_page_pte

[Dev Jain]

#syz test

In commit_anon_folio_batch(), we iterate over all pages pointed to by the
PTE batch. Therefore we need to know the first page of the batch;
currently we derive that via folio_page(folio, 0), but, that takes us
to the first (head) page of the folio instead - our PTE batch may lie
in the middle of the folio, leading to incorrectness.

Bite the bullet and throw away the micro-optimization of reusing the
folio in favour of code simplicity. Derive the page and the folio in
change_pte_range, and pass the page too to commit_anon_folio_batch to
fix the aforementioned issue.

Also, instead of directly adding to the stuct page *page pointer, use
the nth_page() macro for safety.

Fixes: cac1db8c3aad ("mm: optimize mprotect() by PTE batching") 
Signed-off-by: Dev Jain <dev.jain@arm.com>
---
 mm/mprotect.c | 25 +++++++++++--------------
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/mm/mprotect.c b/mm/mprotect.c
index 78bded7acf79..96cd36ed3489 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -120,9 +120,8 @@ static int mprotect_folio_pte_batch(struct folio *folio, pte_t *ptep,
 
 static bool prot_numa_skip(struct vm_area_struct *vma, unsigned long addr,
 			   pte_t oldpte, pte_t *pte, int target_node,
-			   struct folio **foliop)
+			   struct folio *folio)
 {
-	struct folio *folio = NULL;
 	bool ret = true;
 	bool toptier;
 	int nid;
@@ -131,7 +130,6 @@ static bool prot_numa_skip(struct vm_area_struct *vma, unsigned long addr,
 	if (pte_protnone(oldpte))
 		goto skip;
 
-	folio = vm_normal_folio(vma, addr, oldpte);
 	if (!folio)
 		goto skip;
 
@@ -173,7 +171,6 @@ static bool prot_numa_skip(struct vm_area_struct *vma, unsigned long addr,
 		folio_xchg_access_time(folio, jiffies_to_msecs(jiffies));
 
 skip:
-	*foliop = folio;
 	return ret;
 }
 
@@ -231,16 +228,15 @@ static int page_anon_exclusive_sub_batch(int start_idx, int max_len,
  * retrieve sub-batches.
  */
 static void commit_anon_folio_batch(struct vm_area_struct *vma,
-		struct folio *folio, unsigned long addr, pte_t *ptep,
+		struct folio *folio, struct page *first_page, unsigned long addr, pte_t *ptep,
 		pte_t oldpte, pte_t ptent, int nr_ptes, struct mmu_gather *tlb)
 {
-	struct page *first_page = folio_page(folio, 0);
 	bool expected_anon_exclusive;
 	int sub_batch_idx = 0;
 	int len;
 
 	while (nr_ptes) {
-		expected_anon_exclusive = PageAnonExclusive(first_page + sub_batch_idx);
+		expected_anon_exclusive = PageAnonExclusive(nth_page(first_page, sub_batch_idx));
 		len = page_anon_exclusive_sub_batch(sub_batch_idx, nr_ptes,
 					first_page, expected_anon_exclusive);
 		prot_commit_flush_ptes(vma, addr, ptep, oldpte, ptent, len,
@@ -251,7 +247,7 @@ static void commit_anon_folio_batch(struct vm_area_struct *vma,
 }
 
 static void set_write_prot_commit_flush_ptes(struct vm_area_struct *vma,
-		struct folio *folio, unsigned long addr, pte_t *ptep,
+		struct folio *folio, struct page *page, unsigned long addr, pte_t *ptep,
 		pte_t oldpte, pte_t ptent, int nr_ptes, struct mmu_gather *tlb)
 {
 	bool set_write;
@@ -270,7 +266,7 @@ static void set_write_prot_commit_flush_ptes(struct vm_area_struct *vma,
 				       /* idx = */ 0, set_write, tlb);
 		return;
 	}
-	commit_anon_folio_batch(vma, folio, addr, ptep, oldpte, ptent, nr_ptes, tlb);
+	commit_anon_folio_batch(vma, folio, page, addr, ptep, oldpte, ptent, nr_ptes, tlb);
 }
 
 static long change_pte_range(struct mmu_gather *tlb,
@@ -305,15 +301,19 @@ static long change_pte_range(struct mmu_gather *tlb,
 			const fpb_t flags = FPB_RESPECT_SOFT_DIRTY | FPB_RESPECT_WRITE;
 			int max_nr_ptes = (end - addr) >> PAGE_SHIFT;
 			struct folio *folio = NULL;
+			struct page *page;
 			pte_t ptent;
 
+			page = vm_normal_page(vma, addr, oldpte);
+			if (page)
+				folio = page_folio(page);
 			/*
 			 * Avoid trapping faults against the zero or KSM
 			 * pages. See similar comment in change_huge_pmd.
 			 */
 			if (prot_numa) {
 				int ret = prot_numa_skip(vma, addr, oldpte, pte,
-							 target_node, &folio);
+							 target_node, folio);
 				if (ret) {
 
 					/* determine batch to skip */
@@ -323,9 +323,6 @@ static long change_pte_range(struct mmu_gather *tlb,
 				}
 			}
 
-			if (!folio)
-				folio = vm_normal_folio(vma, addr, oldpte);
-
 			nr_ptes = mprotect_folio_pte_batch(folio, pte, oldpte, max_nr_ptes, flags);
 
 			oldpte = modify_prot_start_ptes(vma, addr, pte, nr_ptes);
@@ -351,7 +348,7 @@ static long change_pte_range(struct mmu_gather *tlb,
 			 */
 			if ((cp_flags & MM_CP_TRY_CHANGE_WRITABLE) &&
 			     !pte_write(ptent))
-				set_write_prot_commit_flush_ptes(vma, folio,
+				set_write_prot_commit_flush_ptes(vma, folio, page,
 				addr, pte, oldpte, ptent, nr_ptes, tlb);
 			else
 				prot_commit_flush_ptes(vma, addr, pte, oldpte, ptent,
-- 
2.30.2

Re: [syzbot] [mm?] WARNING in follow_page_pte

[syzbot]

syzbot has bisected this issue to:

commit cac1db8c3aad97d6ffb56ced8868d6cbbbd2bfbe
Author: Dev Jain <dev.jain@arm.com>
Date:   Fri Jul 18 09:02:43 2025 +0000

    mm: optimize mprotect() by PTE batching

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13c746a2580000
start commit:   7e161a991ea7 Merge tag 'i2c-for-6.17-rc1-part2' of git://g..
git tree:       upstream
final oops:     https://syzkaller.appspot.com/x/report.txt?x=102746a2580000
console output: https://syzkaller.appspot.com/x/log.txt?x=17c746a2580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=75e522434dc68cb9
dashboard link: https://syzkaller.appspot.com/bug?extid=57bcc752f0df8bb1365c
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=126e85bc580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=161a22f0580000

Reported-by: syzbot+57bcc752f0df8bb1365c@syzkaller.appspotmail.com
Fixes: cac1db8c3aad ("mm: optimize mprotect() by PTE batching")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Re: [syzbot] [mm?] WARNING in follow_page_pte

[Dev Jain]

On 06/08/25 4:49 pm, Dev Jain wrote:
> #syz test
>
> In commit_anon_folio_batch(), we iterate over all pages pointed to by the
> PTE batch. Therefore we need to know the first page of the batch;
> currently we derive that via folio_page(folio, 0), but, that takes us
> to the first (head) page of the folio instead - our PTE batch may lie
> in the middle of the folio, leading to incorrectness.
>
> Bite the bullet and throw away the micro-optimization of reusing the
> folio in favour of code simplicity. Derive the page and the folio in
> change_pte_range, and pass the page too to commit_anon_folio_batch to
> fix the aforementioned issue.
>
> Also, instead of directly adding to the stuct page *page pointer, use
> the nth_page() macro for safety.
>
> Fixes: cac1db8c3aad ("mm: optimize mprotect() by PTE batching")
> Signed-off-by: Dev Jain <dev.jain@arm.com>
> ---
>   mm/mprotect.c | 25 +++++++++++--------------
>   1 file changed, 11 insertions(+), 14 deletions(-)
>

Oops, this patch is based off mm-hotfixes-unstable, but I guess syzbot
will need it rebased on Torvalds' master?

Re: [syzbot] [mm?] WARNING in follow_page_pte

[David Hildenbrand]

>   static void commit_anon_folio_batch(struct vm_area_struct *vma,
> -		struct folio *folio, unsigned long addr, pte_t *ptep,
> +		struct folio *folio, struct page *first_page, unsigned long addr, pte_t *ptep,
>   		pte_t oldpte, pte_t ptent, int nr_ptes, struct mmu_gather *tlb)
>   {
> -	struct page *first_page = folio_page(folio, 0);
>   	bool expected_anon_exclusive;
>   	int sub_batch_idx = 0;
>   	int len;
>   
>   	while (nr_ptes) {
> -		expected_anon_exclusive = PageAnonExclusive(first_page + sub_batch_idx);
> +		expected_anon_exclusive = PageAnonExclusive(nth_page(first_page, sub_batch_idx));

We shouldn't need nth_page here, for the same reason we don't use it in 
rmap code: we're operating within a single page table and hugetlb does 
not apply.

-- 
Cheers,

David / dhildenb

Re: [syzbot] [mm?] WARNING in follow_page_pte

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+57bcc752f0df8bb1365c@syzkaller.appspotmail.com
Tested-by: syzbot+57bcc752f0df8bb1365c@syzkaller.appspotmail.com

Tested on:

commit:         47905800 Merge tag 'ata-6.17-rc1-fixes' of git://git.k..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=125da2f0580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=75e522434dc68cb9
dashboard link: https://syzkaller.appspot.com/bug?extid=57bcc752f0df8bb1365c
compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
patch:          https://syzkaller.appspot.com/x/patch.diff?x=17c36042580000

Note: testing is done by a robot and is best-effort only.