mm/khugepaged.c | 424 ++++++++++++++++++++++++++++-------------------- 1 file changed, 248 insertions(+), 176 deletions(-)
Here are a bunch of cleanups for collapse_file() that attempt to aid code readability and understanding. This is part 1 out of N, and only attempts to address the main collapse loop. The exit path is still a mess but I figure it's much easier to review if I send this batch as-is, versus sending the whole thing. Based on top of latest mm-unstable. Cc: Zi Yan <ziy@nvidia.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: "Liam R. Howlett" <liam@infradead.org> Cc: Nico Pache <npache@redhat.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Dev Jain <dev.jain@arm.com> Cc: Barry Song <baohua@kernel.org> Cc: Lance Yang <lance.yang@linux.dev> Cc: Usama Arif <usama.arif@linux.dev> Cc: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org Pedro Falcato (8): mm/khugepaged: separate out windy folio logic from collapse_file mm/khugepaged: factor out page cache folio reading mm/khugepaged: factor out and simplify dirty/writeback handling mm/khugepaged: simplify prepare folio locking and exit paths mm/khugepaged: add kerneldoc to prepare_collapse_file_folio() mm/khugepaged: hoist isolation into collapse_isolate_folio() mm/khugepaged: hoist more code into collapse_isolate_folio() mm/khugepaged: fix and flesh out try_to_unmap_flush() comment mm/khugepaged.c | 424 ++++++++++++++++++++++++++++-------------------- 1 file changed, 248 insertions(+), 176 deletions(-) -- 2.55.0
On Mon, Jul 20, 2026 at 8:33 AM Pedro Falcato <pfalcato@suse.de> wrote: > > Here are a bunch of cleanups for collapse_file() that attempt to aid > code readability and understanding. This is part 1 out of N, and only > attempts to address the main collapse loop. The exit path is still a > mess but I figure it's much easier to review if I send this batch as-is, > versus sending the whole thing. Hi Pedro, I have already prepped a cleanup series for collapse_file(). I was waiting for my work here https://lore.kernel.org/lkml/20260715025941.1571316-1-npache@redhat.com/ to be reviewed (and in mm-unstable) before sending it out. Our series have several similarities; for reference, here is my version. https://gitlab.com/npache/linux/-/commits/khugepaged_file_refactor?ref_type=heads Cheers, -- Nico > > Based on top of latest mm-unstable. > > Cc: Zi Yan <ziy@nvidia.com> > Cc: Baolin Wang <baolin.wang@linux.alibaba.com> > Cc: "Liam R. Howlett" <liam@infradead.org> > Cc: Nico Pache <npache@redhat.com> > Cc: Ryan Roberts <ryan.roberts@arm.com> > Cc: Dev Jain <dev.jain@arm.com> > Cc: Barry Song <baohua@kernel.org> > Cc: Lance Yang <lance.yang@linux.dev> > Cc: Usama Arif <usama.arif@linux.dev> > Cc: linux-mm@kvack.org > Cc: linux-kernel@vger.kernel.org > Pedro Falcato (8): > mm/khugepaged: separate out windy folio logic from collapse_file > mm/khugepaged: factor out page cache folio reading > mm/khugepaged: factor out and simplify dirty/writeback handling > mm/khugepaged: simplify prepare folio locking and exit paths > mm/khugepaged: add kerneldoc to prepare_collapse_file_folio() > mm/khugepaged: hoist isolation into collapse_isolate_folio() > mm/khugepaged: hoist more code into collapse_isolate_folio() > mm/khugepaged: fix and flesh out try_to_unmap_flush() comment > > mm/khugepaged.c | 424 ++++++++++++++++++++++++++++-------------------- > 1 file changed, 248 insertions(+), 176 deletions(-) > > -- > 2.55.0 >
On Mon, Jul 20, 2026 at 09:21:11AM -0600, Nico Pache wrote: > On Mon, Jul 20, 2026 at 8:33 AM Pedro Falcato <pfalcato@suse.de> wrote: > > > > Here are a bunch of cleanups for collapse_file() that attempt to aid > > code readability and understanding. This is part 1 out of N, and only > > attempts to address the main collapse loop. The exit path is still a > > mess but I figure it's much easier to review if I send this batch as-is, > > versus sending the whole thing. > > Hi Pedro, > > I have already prepped a cleanup series for collapse_file(). > > I was waiting for my work here > https://lore.kernel.org/lkml/20260715025941.1571316-1-npache@redhat.com/ > to be reviewed (and in mm-unstable) before sending it out. > > Our series have several similarities; for reference, here is my version. > https://gitlab.com/npache/linux/-/commits/khugepaged_file_refactor?ref_type=heads Ugh, this is awkward. Do you have any suggestions on next steps? I can try and take in some of your work on top of this series. But that might be hairy. This situation really does suck (I've definitely been there), but I would prefer not to drop the patchset. -- Pedro
On Mon, Jul 20, 2026 at 1:49 PM Pedro Falcato <pfalcato@suse.de> wrote: > > On Mon, Jul 20, 2026 at 09:21:11AM -0600, Nico Pache wrote: > > On Mon, Jul 20, 2026 at 8:33 AM Pedro Falcato <pfalcato@suse.de> wrote: > > > > > > Here are a bunch of cleanups for collapse_file() that attempt to aid > > > code readability and understanding. This is part 1 out of N, and only > > > attempts to address the main collapse loop. The exit path is still a > > > mess but I figure it's much easier to review if I send this batch as-is, > > > versus sending the whole thing. > > > > Hi Pedro, > > > > I have already prepped a cleanup series for collapse_file(). > > > > I was waiting for my work here > > https://lore.kernel.org/lkml/20260715025941.1571316-1-npache@redhat.com/ > > to be reviewed (and in mm-unstable) before sending it out. > > > > Our series have several similarities; for reference, here is my version. > > https://gitlab.com/npache/linux/-/commits/khugepaged_file_refactor?ref_type=heads > > Ugh, this is awkward. Do you have any suggestions on next steps? Let me review your series and see what differences stand out. You referenced part 1 of N; I think my series covers many of the other parts. I basically broke down each stage of collapse_file() into helpers, and cleaned up each part respectively. Whatever we decide, as long as collapse_file() gets the proper love im ok with it. I did, however, communicate that I was cleaning this up to David, Lorenzo, and others. > > I can try and take in some of your work on top of this series. But that might > be hairy. > > This situation really does suck (I've definitely been there), but I would > prefer not to drop the patchset. Yeah that might be hard. However, there are other parts I cleaned up that you haven't touched in this series so perhaps some of those apply cleanly. Cheers, -- Nico > > -- > Pedro >
On Mon, Jul 20, 2026 at 02:14:45PM -0600, Nico Pache wrote: > On Mon, Jul 20, 2026 at 1:49 PM Pedro Falcato <pfalcato@suse.de> wrote: > > > > On Mon, Jul 20, 2026 at 09:21:11AM -0600, Nico Pache wrote: > > > On Mon, Jul 20, 2026 at 8:33 AM Pedro Falcato <pfalcato@suse.de> wrote: > > > > > > > > Here are a bunch of cleanups for collapse_file() that attempt to aid > > > > code readability and understanding. This is part 1 out of N, and only > > > > attempts to address the main collapse loop. The exit path is still a > > > > mess but I figure it's much easier to review if I send this batch as-is, > > > > versus sending the whole thing. > > > > > > Hi Pedro, > > > > > > I have already prepped a cleanup series for collapse_file(). > > > > > > I was waiting for my work here > > > https://lore.kernel.org/lkml/20260715025941.1571316-1-npache@redhat.com/ > > > to be reviewed (and in mm-unstable) before sending it out. > > > > > > Our series have several similarities; for reference, here is my version. > > > https://gitlab.com/npache/linux/-/commits/khugepaged_file_refactor?ref_type=heads > > > > Ugh, this is awkward. Do you have any suggestions on next steps? > > Let me review your series and see what differences stand out. You > referenced part 1 of N; I think my series covers many of the other > parts. I basically broke down each stage of collapse_file() into > helpers, and cleaned up each part respectively. > > Whatever we decide, as long as collapse_file() gets the proper love im > ok with it. I did, however, communicate that I was cleaning this up to > David, Lorenzo, and others. Yeah I'm keen that we find a good compromise here, as I genuinely very much empathise with both sides of this - being 'pipped' on a series is horrible and we generally really want to avoid that. But I hope that some collaborative effort is possible here? > > > > > I can try and take in some of your work on top of this series. But that might > > be hairy. > > > > This situation really does suck (I've definitely been there), but I would > > prefer not to drop the patchset. > > Yeah that might be hard. However, there are other parts I cleaned up > that you haven't touched in this series so perhaps some of those apply > cleanly. It'd be ideal if you guys could figure out a way to combine both in a series, perhaps with Co-Dev-By or similar? > > Cheers, > -- Nico > > > > > -- > > Pedro > > > I'll leave it to you two to figure things out, I've left some review here already (the general thrust of the series is good and cleaning this... 'organically grown' code is a wonderful thing), but will pause until you figure out a way forwards. Cheers, Lorenzo
On Tue, Jul 21, 2026 at 1:55 AM Lorenzo Stoakes (ARM) <ljs@kernel.org> wrote: > > On Mon, Jul 20, 2026 at 02:14:45PM -0600, Nico Pache wrote: > > On Mon, Jul 20, 2026 at 1:49 PM Pedro Falcato <pfalcato@suse.de> wrote: > > > > > > On Mon, Jul 20, 2026 at 09:21:11AM -0600, Nico Pache wrote: > > > > On Mon, Jul 20, 2026 at 8:33 AM Pedro Falcato <pfalcato@suse.de> wrote: > > > > > > > > > > Here are a bunch of cleanups for collapse_file() that attempt to aid > > > > > code readability and understanding. This is part 1 out of N, and only > > > > > attempts to address the main collapse loop. The exit path is still a > > > > > mess but I figure it's much easier to review if I send this batch as-is, > > > > > versus sending the whole thing. > > > > > > > > Hi Pedro, > > > > > > > > I have already prepped a cleanup series for collapse_file(). > > > > > > > > I was waiting for my work here > > > > https://lore.kernel.org/lkml/20260715025941.1571316-1-npache@redhat.com/ > > > > to be reviewed (and in mm-unstable) before sending it out. > > > > > > > > Our series have several similarities; for reference, here is my version. > > > > https://gitlab.com/npache/linux/-/commits/khugepaged_file_refactor?ref_type=heads > > > > > > Ugh, this is awkward. Do you have any suggestions on next steps? > > > > Let me review your series and see what differences stand out. You > > referenced part 1 of N; I think my series covers many of the other > > parts. I basically broke down each stage of collapse_file() into > > helpers, and cleaned up each part respectively. > > > > Whatever we decide, as long as collapse_file() gets the proper love im > > ok with it. I did, however, communicate that I was cleaning this up to > > David, Lorenzo, and others. > > Yeah I'm keen that we find a good compromise here, as I genuinely very much > empathise with both sides of this - being 'pipped' on a series is horrible and > we generally really want to avoid that. > > But I hope that some collaborative effort is possible here? Yes definitely! Pedro's series covers only part of what my work addresses. I think it will be pretty easy to take his work, and my commits for the rest of the collapse_file() function. > > > > > > > > > I can try and take in some of your work on top of this series. But that might > > > be hairy. > > > > > > This situation really does suck (I've definitely been there), but I would > > > prefer not to drop the patchset. > > > > Yeah that might be hard. However, there are other parts I cleaned up > > that you haven't touched in this series so perhaps some of those apply > > cleanly. > > It'd be ideal if you guys could figure out a way to combine both in a series, > perhaps with Co-Dev-By or similar? I've reached out to him to coordinate this effort :) Thanks, -- Nico > > > > > Cheers, > > -- Nico > > > > > > > > -- > > > Pedro > > > > > > > I'll leave it to you two to figure things out, I've left some review here > already (the general thrust of the series is good and cleaning > this... 'organically grown' code is a wonderful thing), but will pause until you > figure out a way forwards. > > Cheers, Lorenzo >
syzbot ci has tested the following series [v1] mm/khugepaged: collapse_file() cleanups https://lore.kernel.org/all/20260720142913.846902-1-pfalcato@suse.de * [PATCH 1/8] mm/khugepaged: separate out windy folio logic from collapse_file * [PATCH 2/8] mm/khugepaged: factor out page cache folio reading * [PATCH 3/8] mm/khugepaged: factor out and simplify dirty/writeback handling * [PATCH 4/8] mm/khugepaged: simplify prepare folio locking and exit paths * [PATCH 5/8] mm/khugepaged: add kerneldoc to prepare_collapse_file_folio() * [PATCH 6/8] mm/khugepaged: hoist isolation into collapse_isolate_folio() * [PATCH 7/8] mm/khugepaged: hoist more code into collapse_isolate_folio() * [PATCH 8/8] mm/khugepaged: fix and flesh out try_to_unmap_flush() comment and found the following issue: WARNING: bad unlock balance in collapse_scan_file Full report is available here: https://ci.syzbot.org/series/cc30d9d4-857a-45de-a8e8-b99f9346d0da *** WARNING: bad unlock balance in collapse_scan_file tree: mm-new URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm.git base: c872b70f5d6c742ad34b8e838c92af81c8920b3e arch: amd64 compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8 config: https://ci.syzbot.org/builds/e6e237b7-5a64-4732-bb37-4e62c3103d4a/config syz repro: https://ci.syzbot.org/findings/51ee94c3-7fe6-47f6-81ed-a53cf51bb3f9/syz_repro ===================================== WARNING: bad unlock balance detected! syzkaller #0 Not tainted ------------------------------------- syz.0.17/5868 is trying to release lock (&xa->xa_lock) at: [<ffffffff823ac70f>] spin_unlock_irq include/linux/spinlock.h:402 [inline] [<ffffffff823ac70f>] prepare_collapse_file_folio mm/khugepaged.c:2331 [inline] [<ffffffff823ac70f>] collapse_file mm/khugepaged.c:2539 [inline] [<ffffffff823ac70f>] collapse_scan_file+0x2cbf/0x4dc0 mm/khugepaged.c:2849 but there are no more locks to release! other info that might help us debug this: no locks held by syz.0.17/5868. stack backtrace: CPU: 0 UID: 0 PID: 5868 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 Call Trace: <TASK> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_unlock_imbalance_bug+0xdc/0xf0 kernel/locking/lockdep.c:5299 __lock_release kernel/locking/lockdep.c:5528 [inline] lock_release+0x1fb/0x3c0 kernel/locking/lockdep.c:5912 __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:185 [inline] _raw_spin_unlock_irq+0x16/0x50 kernel/locking/spinlock.c:206 spin_unlock_irq include/linux/spinlock.h:402 [inline] prepare_collapse_file_folio mm/khugepaged.c:2331 [inline] collapse_file mm/khugepaged.c:2539 [inline] collapse_scan_file+0x2cbf/0x4dc0 mm/khugepaged.c:2849 collapse_single_pmd+0x2b1/0x3da0 mm/khugepaged.c:2884 madvise_collapse+0x2cf/0x790 mm/khugepaged.c:3310 madvise_vma_behavior+0x115f/0x4170 mm/madvise.c:1363 madvise_walk_vmas+0x576/0xb00 mm/madvise.c:1712 madvise_do_behavior+0x385/0x540 mm/madvise.c:1907 do_madvise+0x327/0x3a0 mm/madvise.c:2005 __do_sys_madvise mm/madvise.c:2014 [inline] __se_sys_madvise mm/madvise.c:2012 [inline] __x64_sys_madvise+0xa6/0xc0 mm/madvise.c:2012 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb60079de99 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:00007fb6015c0028 EFLAGS: 00000246 ORIG_RAX: 000000000000001c RAX: ffffffffffffffda RBX: 00007fb600a25fa0 RCX: 00007fb60079de99 RDX: 0000000000000019 RSI: 0000000000600003 RDI: 0000200000000000 RBP: 00007fb600833eaf R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fb600a26038 R14: 00007fb600a25fa0 R15: 00007ffc7db2f618 </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. To test a patch for this bug, please reply with `#syz test` (should be on a separate line). The patch should be attached to the email. Note: arguments like custom git repos and branches are not supported.
© 2016 - 2026 Red Hat, Inc.