* Re: [syzbot ci] Separate compound page from folio
2026-01-30 8:15 ` [syzbot ci] Re: Separate compound page from folio syzbot ci
@ 2026-01-30 16:39 ` Zi Yan
2026-01-30 16:41 ` syzbot ci
0 siblings, 1 reply; 3+ messages in thread
From: Zi Yan @ 2026-01-30 16:39 UTC (permalink / raw)
To: syzbot ci
Cc: akpm, apopple, axboe, balbirs, baohua, baolin.wang, david,
dev.jain, hannes, io-uring, jackmanb, jgg, lance.yang,
liam.howlett, linux-kernel, linux-mm, lorenzo.stoakes, mhocko,
muchun.song, npache, osalvador, rppt, ryan.roberts, surenb,
vbabka, willy, syzbot, syzkaller-bugs
On 30 Jan 2026, at 3:15, syzbot ci wrote:
> syzbot ci has tested the following series
>
> [v1] Separate compound page from folio
> https://lore.kernel.org/all/20260130034818.472804-1-ziy@nvidia.com
> * [RFC PATCH 1/5] io_uring: allocate folio in io_mem_alloc_compound() and function rename
> * [RFC PATCH 2/5] mm/huge_memory: use page_rmappable_folio() to convert after-split folios
> * [RFC PATCH 3/5] mm/hugetlb: set large_rmappable on hugetlb and avoid deferred_list handling
> * [RFC PATCH 4/5] mm: only use struct page in compound_nr() and compound_order()
> * [RFC PATCH 5/5] mm: code separation for compound page and folio
>
> and found the following issue:
> WARNING in __folio_large_mapcount_sanity_checks
>
> Full report is available here:
> https://ci.syzbot.org/series/f64f0297-d388-4cfa-b3be-f05819d0ce34
>
> ***
>
> WARNING in __folio_large_mapcount_sanity_checks
>
> tree: mm-new
> URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm.git
> base: 0241748f8b68fc2bf637f4901b9d7ca660d177ca
> arch: amd64
> compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
> config: https://ci.syzbot.org/builds/76dc5ea6-0ff5-410b-8b1f-72e5607a704e/config
> C repro: https://ci.syzbot.org/findings/a308f1d6-69e2-4ebc-80a9-b51d9dc02851/c_repro
> syz repro: https://ci.syzbot.org/findings/a308f1d6-69e2-4ebc-80a9-b51d9dc02851/syz_repro
>
> ------------[ cut here ]------------
> diff > folio_large_nr_pages(folio)
> WARNING: ./include/linux/rmap.h:148 at __folio_large_mapcount_sanity_checks+0x499/0x6b0 include/linux/rmap.h:148, CPU#1: syz.0.17/5988
> Modules linked in:
> CPU: 1 UID: 0 PID: 5988 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:__folio_large_mapcount_sanity_checks+0x499/0x6b0 include/linux/rmap.h:148
> Code: 5f 5d e9 4a 4e 64 09 cc e8 84 d8 aa ff 90 0f 0b 90 e9 82 fc ff ff e8 76 d8 aa ff 90 0f 0b 90 e9 8f fc ff ff e8 68 d8 aa ff 90 <0f> 0b 90 e9 b8 fc ff ff e8 5a d8 aa ff 90 0f 0b 90 e9 f2 fc ff ff
> RSP: 0018:ffffc900040e72f8 EFLAGS: 00010293
> RAX: ffffffff8217c0f8 RBX: ffffea0006ef5c00 RCX: ffff888105fdba80
> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
> RBP: 0000000000000001 R08: ffffea0006ef5c07 R09: 1ffffd4000ddeb80
> R10: dffffc0000000000 R11: fffff94000ddeb81 R12: 0000000000000001
> R13: 0000000000000000 R14: 1ffffd4000ddeb8f R15: ffffea0006ef5c78
> FS: 00005555867b3500(0000) GS:ffff8882a9923000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00002000000000c0 CR3: 0000000103ab0000 CR4: 00000000000006f0
> Call Trace:
> <TASK>
> folio_add_return_large_mapcount include/linux/rmap.h:184 [inline]
> __folio_add_rmap mm/rmap.c:1377 [inline]
> __folio_add_file_rmap mm/rmap.c:1696 [inline]
> folio_add_file_rmap_ptes+0x4c2/0xe60 mm/rmap.c:1722
> insert_page_into_pte_locked+0x5ab/0x910 mm/memory.c:2378
> insert_page+0x186/0x2d0 mm/memory.c:2398
> packet_mmap+0x360/0x530 net/packet/af_packet.c:4622
> vfs_mmap include/linux/fs.h:2053 [inline]
> mmap_file mm/internal.h:167 [inline]
> __mmap_new_file_vma mm/vma.c:2468 [inline]
> __mmap_new_vma mm/vma.c:2532 [inline]
> __mmap_region mm/vma.c:2759 [inline]
> mmap_region+0x18fe/0x2240 mm/vma.c:2837
> do_mmap+0xc39/0x10c0 mm/mmap.c:559
> vm_mmap_pgoff+0x2c9/0x4f0 mm/util.c:581
> ksys_mmap_pgoff+0x51e/0x760 mm/mmap.c:605
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f5d7399acb9
> 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:00007ffe9f3eea78 EFLAGS: 00000246 ORIG_RAX: 0000000000000009
> RAX: ffffffffffffffda RBX: 00007f5d73c15fa0 RCX: 00007f5d7399acb9
> RDX: 0000000000000002 RSI: 0000000000030000 RDI: 0000200000000000
> RBP: 00007f5d73a08bf7 R08: 0000000000000003 R09: 0000000000000000
> R10: 0000000000000011 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007f5d73c15fac R14: 00007f5d73c15fa0 R15: 00007f5d73c15fa0
> </TASK>
>
>
> ***
>
> 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.
The issue comes from alloc_one_pg_vec_page() in net/packet/af_packet.c.
It allocates a compound page with __GFP_COMP, but latter does vm_insert_page()
in packet_mmap(), using it as a folio.
The fix below is a hack. We will need a get_free_folios() instead.
I will check all __GFP_COMP callers to find out which ones are using it
as a folio and which ones are using it as a compound page. I suspect
most are using it as a folio.
#syz test
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 2194a6b3a062..90858d20dfbe 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5311,6 +5311,8 @@ unsigned long get_free_pages_noprof(gfp_t gfp_mask, unsigned int order)
page = alloc_pages_noprof(gfp_mask & ~__GFP_HIGHMEM, order);
if (!page)
return 0;
+ if (gfp_mask & __GFP_COMP)
+ return (unsigned long)folio_address(page_rmappable_folio(page));
return (unsigned long) page_address(page);
}
EXPORT_SYMBOL(get_free_pages_noprof);
Best Regards,
Yan, Zi
^ permalink raw reply related [flat|nested] 3+ messages in thread