[PATCH 0/6] mm: batch rmap walks during large folio migration

Shivank Garg posted 6 patches 1 week, 6 days ago
include/linux/rmap.h |  52 +++++--
mm/internal.h        |  36 +++--
mm/migrate.c         | 190 ++++++++++++++++-------
mm/rmap.c            | 427 +++++++++++++++++++++++++++++++++------------------
4 files changed, 464 insertions(+), 241 deletions(-)
[PATCH 0/6] mm: batch rmap walks during large folio migration
Posted by Shivank Garg 1 week, 6 days ago
Migrating a PTE-mapped large folio currently walks the folio's rmap
one page at a time. It does so twice per migration:
1. try_to_migrate_one(): Replace present PTEs with migration entries
2. remove_migration_pte(): Restore migration entries to working PTEs.

For a folio with N contiguous PTEs, each walk repeats page_vma_mapped_walk()
and the associated operation per subpage of the folio. (256 iterations
for 1M folio).

This series enables both walks to process a batch of consecutive PTEs
that map the same large folio and do some refactoring and clean up on
the way.

Performance:

AMD EPYC ZEN 3, 2-socket system (1 node per socket).
move_pages() migrating 1 GB from node 0 -> node 1, throughput
in GB/s:
		         batch-	        batch-restore +
folio     vanilla        restore        unmap          restore%  restore+unmap%
4K        2.98±0.09      2.95±0.07      3.06±0.05        -1.0%    +2.6%
64K       6.16±0.09      6.24±0.08      7.80±0.08        +1.3%   +26.6%
256K      6.85±0.06      6.85±0.09      9.54±0.19        +0.0%   +39.3%
1M        7.06±0.09      7.17±0.09      9.89±0.06        +1.5%   +40.1%
2M       10.97±0.17     10.67±0.13     10.69±0.15        -2.7%    -2.6%

In plain migration, the folio copy itself dominate the cost, so these rmap walk
savings are only partly visible end-to-end.
When the folio copy is batched-copy and offloaded to DMA engine [1], the copy is
no longer the bottlneck and rmap-walk batching translates into much larger gains:

This series + [1], DMA Offload on PTDMA (DCBM), 16 channels:

		     batch-copy
folio   vanilla      -offload(dcbm)  dcbm+restore   dcbm+restore+unmap
4K      3.36 ± 0.10   4.16 ± 0.18     4.10 ± 0.14    4.12 ± 0.13
64K     6.16 ± 0.47   9.63 ± 0.23    10.00 ± 0.33   14.63 ± 0.14
256K    6.70 ± 0.09  12.98 ± 0.18    13.52 ± 0.15   32.30 ± 0.65    (2.38x)
1M      6.99 ± 0.02  14.32 ± 0.67    14.84 ± 0.17   38.97 ± 1.03    (2.62x)
2M     10.74 ± 0.29  64.25 ± 1.48    65.36 ± 1.00   64.97 ± 1.75

[1] https://lore.kernel.org/linux-mm/20260630-shivank-batch-migrate-offload-v6-0-da95d7e8b8a2@amd.com

Applies cleanly on mm-new 10-07-26 (61cccb8363f).

Signed-off-by: Shivank Garg <shivankg@amd.com>
---
Dev Jain (1):
      mm/rmap: Add batched version of folio_try_share_anon_rmap_pte

Shivank Garg (5):
      mm: factor out generic PTE batch detection from swap_pte_batch()
      mm/migrate: split remove_migration_pte_hugetlb() out of remove_migration_pte()
      mm/migrate: batch the restore-side migration rmap walk
      mm/rmap: split try_to_migrate_hugetlb_one() out of try_to_migrate_one()
      mm/rmap: batch the unmap of large folios in try_to_migrate_one()

 include/linux/rmap.h |  52 +++++--
 mm/internal.h        |  36 +++--
 mm/migrate.c         | 190 ++++++++++++++++-------
 mm/rmap.c            | 427 +++++++++++++++++++++++++++++++++------------------
 4 files changed, 464 insertions(+), 241 deletions(-)
---
base-commit: 61cccb8363fcc282d4ae0555b8739dd227f5ad0b
change-id: 20260701-migrate-rmap-batch-8ecc04de1905

Best regards,
-- 
Shivank Garg <shivankg@amd.com>

Re: [PATCH 0/6] mm: batch rmap walks during large folio migration
Posted by Andrew Morton 1 week, 4 days ago
On Sun, 12 Jul 2026 07:38:46 +0000 Shivank Garg <shivankg@amd.com> wrote:

> Performance:
> 
> AMD EPYC ZEN 3, 2-socket system (1 node per socket).
> move_pages() migrating 1 GB from node 0 -> node 1, throughput
> in GB/s:
> 		         batch-	        batch-restore +
> folio     vanilla        restore        unmap          restore%  restore+unmap%
> 4K        2.98±0.09      2.95±0.07      3.06±0.05        -1.0%    +2.6%
> 64K       6.16±0.09      6.24±0.08      7.80±0.08        +1.3%   +26.6%
> 256K      6.85±0.06      6.85±0.09      9.54±0.19        +0.0%   +39.3%
> 1M        7.06±0.09      7.17±0.09      9.89±0.06        +1.5%   +40.1%
> 2M       10.97±0.17     10.67±0.13     10.69±0.15        -2.7%    -2.6%
> 
> In plain migration, the folio copy itself dominate the cost, so these rmap walk
> savings are only partly visible end-to-end.
> When the folio copy is batched-copy and offloaded to DMA engine [1], the copy is
> no longer the bottlneck and rmap-walk batching translates into much larger gains:
> 
> This series + [1], DMA Offload on PTDMA (DCBM), 16 channels:
> 
> 		     batch-copy
> folio   vanilla      -offload(dcbm)  dcbm+restore   dcbm+restore+unmap
> 4K      3.36 ± 0.10   4.16 ± 0.18     4.10 ± 0.14    4.12 ± 0.13
> 64K     6.16 ± 0.47   9.63 ± 0.23    10.00 ± 0.33   14.63 ± 0.14
> 256K    6.70 ± 0.09  12.98 ± 0.18    13.52 ± 0.15   32.30 ± 0.65    (2.38x)
> 1M      6.99 ± 0.02  14.32 ± 0.67    14.84 ± 0.17   38.97 ± 1.03    (2.62x)
> 2M     10.74 ± 0.29  64.25 ± 1.48    65.36 ± 1.00   64.97 ± 1.75

Well dang.

Thanks.  I'll await reviewer input on this series.

Sashiko said things:
	https://sashiko.dev/#/patchset/20260712-migrate-rmap-batch-v1-0-872a734431d1@amd.com
Re: [PATCH 0/6] mm: batch rmap walks during large folio migration
Posted by Garg, Shivank 1 week, 4 days ago

On 7/14/2026 7:35 AM, Andrew Morton wrote:
> On Sun, 12 Jul 2026 07:38:46 +0000 Shivank Garg <shivankg@amd.com> wrote:
> 
>> Performance:
>>
>> AMD EPYC ZEN 3, 2-socket system (1 node per socket).
>> move_pages() migrating 1 GB from node 0 -> node 1, throughput
>> in GB/s:
>> 		         batch-	        batch-restore +
>> folio     vanilla        restore        unmap          restore%  restore+unmap%
>> 4K        2.98±0.09      2.95±0.07      3.06±0.05        -1.0%    +2.6%
>> 64K       6.16±0.09      6.24±0.08      7.80±0.08        +1.3%   +26.6%
>> 256K      6.85±0.06      6.85±0.09      9.54±0.19        +0.0%   +39.3%
>> 1M        7.06±0.09      7.17±0.09      9.89±0.06        +1.5%   +40.1%
>> 2M       10.97±0.17     10.67±0.13     10.69±0.15        -2.7%    -2.6%
>>
>> In plain migration, the folio copy itself dominate the cost, so these rmap walk
>> savings are only partly visible end-to-end.
>> When the folio copy is batched-copy and offloaded to DMA engine [1], the copy is
>> no longer the bottlneck and rmap-walk batching translates into much larger gains:
>>
>> This series + [1], DMA Offload on PTDMA (DCBM), 16 channels:
>>
>> 		     batch-copy
>> folio   vanilla      -offload(dcbm)  dcbm+restore   dcbm+restore+unmap
>> 4K      3.36 ± 0.10   4.16 ± 0.18     4.10 ± 0.14    4.12 ± 0.13
>> 64K     6.16 ± 0.47   9.63 ± 0.23    10.00 ± 0.33   14.63 ± 0.14
>> 256K    6.70 ± 0.09  12.98 ± 0.18    13.52 ± 0.15   32.30 ± 0.65    (2.38x)
>> 1M      6.99 ± 0.02  14.32 ± 0.67    14.84 ± 0.17   38.97 ± 1.03    (2.62x)
>> 2M     10.74 ± 0.29  64.25 ± 1.48    65.36 ± 1.00   64.97 ± 1.75
> 
> Well dang.
> 
> Thanks.  I'll await reviewer input on this series.
> 
> Sashiko said things:
> 	https://sashiko.dev/#/patchset/20260712-migrate-rmap-batch-v1-0-872a734431d1@amd.com

Thanks Andrew.
I'm working on this and the syzbot reported issue.

Best regards,
Shivank
Re: [PATCH 0/6] mm: batch rmap walks during large folio migration
Posted by David Hildenbrand (Arm) 1 week, 4 days ago
On 7/12/26 09:38, Shivank Garg wrote:
> Migrating a PTE-mapped large folio currently walks the folio's rmap
> one page at a time. It does so twice per migration:
> 1. try_to_migrate_one(): Replace present PTEs with migration entries
> 2. remove_migration_pte(): Restore migration entries to working PTEs.
> 
> For a folio with N contiguous PTEs, each walk repeats page_vma_mapped_walk()
> and the associated operation per subpage of the folio. (256 iterations
> for 1M folio).
> 
> This series enables both walks to process a batch of consecutive PTEs
> that map the same large folio and do some refactoring and clean up on
> the way.
> 
> Performance:
> 
> AMD EPYC ZEN 3, 2-socket system (1 node per socket).
> move_pages() migrating 1 GB from node 0 -> node 1, throughput
> in GB/s:
> 		         batch-	        batch-restore +
> folio     vanilla        restore        unmap          restore%  restore+unmap%
> 4K        2.98±0.09      2.95±0.07      3.06±0.05        -1.0%    +2.6%
> 64K       6.16±0.09      6.24±0.08      7.80±0.08        +1.3%   +26.6%
> 256K      6.85±0.06      6.85±0.09      9.54±0.19        +0.0%   +39.3%
> 1M        7.06±0.09      7.17±0.09      9.89±0.06        +1.5%   +40.1%
> 2M       10.97±0.17     10.67±0.13     10.69±0.15        -2.7%    -2.6%
> 
> In plain migration, the folio copy itself dominate the cost, so these rmap walk
> savings are only partly visible end-to-end.
> When the folio copy is batched-copy and offloaded to DMA engine [1], the copy is
> no longer the bottlneck and rmap-walk batching translates into much larger gains:
> 
> This series + [1], DMA Offload on PTDMA (DCBM), 16 channels:
> 
> 		     batch-copy
> folio   vanilla      -offload(dcbm)  dcbm+restore   dcbm+restore+unmap
> 4K      3.36 ± 0.10   4.16 ± 0.18     4.10 ± 0.14    4.12 ± 0.13
> 64K     6.16 ± 0.47   9.63 ± 0.23    10.00 ± 0.33   14.63 ± 0.14
> 256K    6.70 ± 0.09  12.98 ± 0.18    13.52 ± 0.15   32.30 ± 0.65    (2.38x)
> 1M      6.99 ± 0.02  14.32 ± 0.67    14.84 ± 0.17   38.97 ± 1.03    (2.62x)
> 2M     10.74 ± 0.29  64.25 ± 1.48    65.36 ± 1.00   64.97 ± 1.75
> 
> [1] https://lore.kernel.org/linux-mm/20260630-shivank-batch-migrate-offload-v6-0-da95d7e8b8a2@amd.com
> 
> Applies cleanly on mm-new 10-07-26 (61cccb8363f).
> 
> Signed-off-by: Shivank Garg <shivankg@amd.com>
> ---
> Dev Jain (1):
>       mm/rmap: Add batched version of folio_try_share_anon_rmap_pte

This would ideally be based on Dev's series instead if including a patch from
his series.

-- 
Cheers,

David
Re: [PATCH 0/6] mm: batch rmap walks during large folio migration
Posted by Garg, Shivank 1 week, 3 days ago

On 7/14/2026 4:25 PM, David Hildenbrand (Arm) wrote:
> On 7/12/26 09:38, Shivank Garg wrote:
>> Migrating a PTE-mapped large folio currently walks the folio's rmap
>> one page at a time. It does so twice per migration:
>> 1. try_to_migrate_one(): Replace present PTEs with migration entries
>> 2. remove_migration_pte(): Restore migration entries to working PTEs.
>>
>> For a folio with N contiguous PTEs, each walk repeats page_vma_mapped_walk()
>> and the associated operation per subpage of the folio. (256 iterations
>> for 1M folio).
>>
>> This series enables both walks to process a batch of consecutive PTEs
>> that map the same large folio and do some refactoring and clean up on
>> the way.
>>
>> Performance:
>>
>> AMD EPYC ZEN 3, 2-socket system (1 node per socket).
>> move_pages() migrating 1 GB from node 0 -> node 1, throughput
>> in GB/s:
>> 		         batch-	        batch-restore +
>> folio     vanilla        restore        unmap          restore%  restore+unmap%
>> 4K        2.98±0.09      2.95±0.07      3.06±0.05        -1.0%    +2.6%
>> 64K       6.16±0.09      6.24±0.08      7.80±0.08        +1.3%   +26.6%
>> 256K      6.85±0.06      6.85±0.09      9.54±0.19        +0.0%   +39.3%
>> 1M        7.06±0.09      7.17±0.09      9.89±0.06        +1.5%   +40.1%
>> 2M       10.97±0.17     10.67±0.13     10.69±0.15        -2.7%    -2.6%
>>
>> In plain migration, the folio copy itself dominate the cost, so these rmap walk
>> savings are only partly visible end-to-end.
>> When the folio copy is batched-copy and offloaded to DMA engine [1], the copy is
>> no longer the bottlneck and rmap-walk batching translates into much larger gains:
>>
>> This series + [1], DMA Offload on PTDMA (DCBM), 16 channels:
>>
>> 		     batch-copy
>> folio   vanilla      -offload(dcbm)  dcbm+restore   dcbm+restore+unmap
>> 4K      3.36 ± 0.10   4.16 ± 0.18     4.10 ± 0.14    4.12 ± 0.13
>> 64K     6.16 ± 0.47   9.63 ± 0.23    10.00 ± 0.33   14.63 ± 0.14
>> 256K    6.70 ± 0.09  12.98 ± 0.18    13.52 ± 0.15   32.30 ± 0.65    (2.38x)
>> 1M      6.99 ± 0.02  14.32 ± 0.67    14.84 ± 0.17   38.97 ± 1.03    (2.62x)
>> 2M     10.74 ± 0.29  64.25 ± 1.48    65.36 ± 1.00   64.97 ± 1.75
>>
>> [1] https://lore.kernel.org/linux-mm/20260630-shivank-batch-migrate-offload-v6-0-da95d7e8b8a2@amd.com
>>
>> Applies cleanly on mm-new 10-07-26 (61cccb8363f).
>>
>> Signed-off-by: Shivank Garg <shivankg@amd.com>
>> ---
>> Dev Jain (1):
>>       mm/rmap: Add batched version of folio_try_share_anon_rmap_pte
> 
> This would ideally be based on Dev's series instead if including a patch from
> his series.
> 

Sure, make sense. I will rebase on this.

I initially thought that including this patch will make series complete to easily apply and test.

Thanks,
Shivank
[syzbot ci] Re: mm: batch rmap walks during large folio migration
Posted by syzbot ci 1 week, 6 days ago
syzbot ci has tested the following series

[v1] mm: batch rmap walks during large folio migration
https://lore.kernel.org/all/20260712-migrate-rmap-batch-v1-0-872a734431d1@amd.com
* [PATCH 1/6] mm/rmap: Add batched version of folio_try_share_anon_rmap_pte
* [PATCH 2/6] mm: factor out generic PTE batch detection from swap_pte_batch()
* [PATCH 3/6] mm/migrate: split remove_migration_pte_hugetlb() out of remove_migration_pte()
* [PATCH 4/6] mm/migrate: batch the restore-side migration rmap walk
* [PATCH 5/6] mm/rmap: split try_to_migrate_hugetlb_one() out of try_to_migrate_one()
* [PATCH 6/6] mm/rmap: batch the unmap of large folios in try_to_migrate_one()

and found the following issues:
* BUG: scheduling while atomic in exit_to_user_mode_loop
* BUG: sleeping function called from invalid context in migrate_pages
* BUG: sleeping function called from invalid context in migrate_pages_batch
* BUG: sleeping function called from invalid context in move_pages
* BUG: sleeping function called from invalid context in store_status

Full report is available here:
https://ci.syzbot.org/series/f6ed0914-22d0-4ad7-be5e-be4ed8fb9961

***

BUG: scheduling while atomic in exit_to_user_mode_loop

tree:      mm-new
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm.git
base:      61cccb8363fcc282d4ae0555b8739dd227f5ad0b
arch:      amd64
compiler:  Debian clang version 22.1.6 (++20260514074242+fc4aad7b5db3-1~exp1~20260514074407.73), Debian LLD 22.1.6
config:    https://ci.syzbot.org/builds/a27db994-58f5-48f4-a7f5-528b63f5a7c6/config
syz repro: https://ci.syzbot.org/findings/72fb0597-196f-4679-88a2-7d2dafda8454/syz_repro

BUG: scheduling while atomic: syz.0.17/5797/0x00000002
1 lock held by syz.0.17/5797:
 #0: ffff88810aa64e58 (ptlock_ptr(ptdesc)){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline]
 #0: ffff88810aa64e58 (ptlock_ptr(ptdesc)){+.+.}-{3:3}, at: huge_pte_lock+0x17b/0x1e0 include/linux/hugetlb.h:1318
Modules linked in:
Preemption disabled at:
[<0000000000000000>] 0x0
Kernel panic - not syncing: scheduling while atomic: panic_on_warn set ...
CPU: 0 UID: 0 PID: 5797 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>
 vpanic+0x56c/0xa60 kernel/panic.c:651
 panic+0xc5/0xd0 kernel/panic.c:788
 check_panic_on_warn+0x89/0xb0 kernel/panic.c:525
 __schedule_bug+0xf6/0x150 kernel/sched/core.c:6061
 schedule_debug kernel/sched/core.c:6090 [inline]
 __schedule+0x189d/0x56c0 kernel/sched/core.c:7083
 __schedule_loop kernel/sched/core.c:7311 [inline]
 schedule+0x164/0x2b0 kernel/sched/core.c:7326
 __exit_to_user_mode_loop kernel/entry/common.c:55 [inline]
 exit_to_user_mode_loop+0x83/0x730 kernel/entry/common.c:101
 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
 syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:230 [inline]
 syscall_exit_to_user_mode include/linux/entry-common.h:318 [inline]
 do_syscall_64+0x353/0x580 arch/x86/entry/syscall_64.c:100
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f1b3439ce59
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:00007ffc9098d528 EFLAGS: 00000246 ORIG_RAX: 00000000000000ed
RAX: 0000000000000000 RBX: 00007f1b34615fa0 RCX: 00007f1b3439ce59
RDX: 0000000000004000 RSI: 0000000000002000 RDI: 0000200000195000
RBP: 00007f1b34432e6f R08: 0000000000000008 R09: 0000000000000003
R10: 0000200000000400 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f1b34615fac R14: 00007f1b34615fa0 R15: 00007f1b34615fa0
 </TASK>
Kernel Offset: disabled
Rebooting in 86400 seconds..


***

BUG: sleeping function called from invalid context in migrate_pages

tree:      mm-new
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm.git
base:      61cccb8363fcc282d4ae0555b8739dd227f5ad0b
arch:      amd64
compiler:  Debian clang version 22.1.6 (++20260514074242+fc4aad7b5db3-1~exp1~20260514074407.73), Debian LLD 22.1.6
config:    https://ci.syzbot.org/builds/a27db994-58f5-48f4-a7f5-528b63f5a7c6/config
syz repro: https://ci.syzbot.org/findings/9dd2d2c8-a699-4e7c-8f73-4400d3057853/syz_repro

BUG: sleeping function called from invalid context at mm/migrate.c:1741
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 5809, name: syz.0.17
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
1 lock held by syz.0.17/5809:
 #0: ffff88817766d6d8 (ptlock_ptr(ptdesc)){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline]
 #0: ffff88817766d6d8 (ptlock_ptr(ptdesc)){+.+.}-{3:3}, at: huge_pte_lock+0x17b/0x1e0 include/linux/hugetlb.h:1318
Preemption disabled at:
[<0000000000000000>] 0x0
CPU: 1 UID: 0 PID: 5809 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
 __might_resched+0x378/0x4d0 kernel/sched/core.c:9197
 migrate_hugetlbs mm/migrate.c:1741 [inline]
 migrate_pages+0x49b/0x27e0 mm/migrate.c:2196
 do_mbind mm/mempolicy.c:1617 [inline]
 kernel_mbind mm/mempolicy.c:1760 [inline]
 __do_sys_mbind mm/mempolicy.c:1834 [inline]
 __se_sys_mbind+0xe82/0x10e0 mm/mempolicy.c:1830
 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:0x7fc92ad9ce59
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:00007fc92bc65028 EFLAGS: 00000246 ORIG_RAX: 00000000000000ed
RAX: ffffffffffffffda RBX: 00007fc92b015fa0 RCX: 00007fc92ad9ce59
RDX: 0000000000000001 RSI: 0000000000600000 RDI: 0000200000000000
RBP: 00007fc92ae32e6f R08: 0000000000000000 R09: 0000000000000003
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fc92b016038 R14: 00007fc92b015fa0 R15: 00007ffed35b2a68
 </TASK>

======================================================


***

BUG: sleeping function called from invalid context in migrate_pages_batch

tree:      mm-new
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm.git
base:      61cccb8363fcc282d4ae0555b8739dd227f5ad0b
arch:      amd64
compiler:  Debian clang version 22.1.6 (++20260514074242+fc4aad7b5db3-1~exp1~20260514074407.73), Debian LLD 22.1.6
config:    https://ci.syzbot.org/builds/a27db994-58f5-48f4-a7f5-528b63f5a7c6/config
syz repro: https://ci.syzbot.org/findings/1c235813-ad03-46d5-93c7-2702e3513739/syz_repro

BUG: sleeping function called from invalid context at mm/migrate.c:1923
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 5820, name: syz.1.20
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
1 lock held by syz.1.20/5820:
 #0: ffff88810903b618 (ptlock_ptr(ptdesc)){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline]
 #0: ffff88810903b618 (ptlock_ptr(ptdesc)){+.+.}-{3:3}, at: huge_pte_lock+0x17b/0x1e0 include/linux/hugetlb.h:1318
Preemption disabled at:
[<0000000000000000>] 0x0
CPU: 1 UID: 0 PID: 5820 Comm: syz.1.20 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
 __might_resched+0x378/0x4d0 kernel/sched/core.c:9197
 migrate_pages_batch+0x5c5/0x5020 mm/migrate.c:1923
 migrate_pages_sync mm/migrate.c:2115 [inline]
 migrate_pages+0x1a8b/0x27e0 mm/migrate.c:2224
 migrate_to_node mm/mempolicy.c:1322 [inline]
 do_migrate_pages+0x656/0x8b0 mm/mempolicy.c:1421
 kernel_migrate_pages mm/mempolicy.c:1935 [inline]
 __do_sys_migrate_pages mm/mempolicy.c:1953 [inline]
 __se_sys_migrate_pages+0xaa2/0xc90 mm/mempolicy.c:1949
 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:0x7f1175d9ce59
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:00007f1176c21028 EFLAGS: 00000246 ORIG_RAX: 0000000000000100
RAX: ffffffffffffffda RBX: 00007f1176015fa0 RCX: 00007f1175d9ce59
RDX: 0000200000000000 RSI: 0000000000000004 RDI: 0000000000000000
RBP: 00007f1175e32e6f R08: 0000000000000000 R09: 0000000000000000
R10: 0000200000000300 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f1176016038 R14: 00007f1176015fa0 R15: 00007ffd17a9f8a8
 </TASK>

======================================================


***

BUG: sleeping function called from invalid context in move_pages

tree:      mm-new
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm.git
base:      61cccb8363fcc282d4ae0555b8739dd227f5ad0b
arch:      amd64
compiler:  Debian clang version 22.1.6 (++20260514074242+fc4aad7b5db3-1~exp1~20260514074407.73), Debian LLD 22.1.6
config:    https://ci.syzbot.org/builds/a27db994-58f5-48f4-a7f5-528b63f5a7c6/config
syz repro: https://ci.syzbot.org/findings/5cf317a6-38fc-4f7b-aa15-e8cca68ee0f8/syz_repro

BUG: sleeping function called from invalid context at mm/migrate.c:2320
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 5872, name: syz.0.21
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
1 lock held by syz.0.21/5872:
 #0: ffff88810e2682b8 (ptlock_ptr(ptdesc)){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline]
 #0: ffff88810e2682b8 (ptlock_ptr(ptdesc)){+.+.}-{3:3}, at: huge_pte_lock+0x17b/0x1e0 include/linux/hugetlb.h:1318
Preemption disabled at:
[<0000000000000000>] 0x0
CPU: 0 UID: 0 PID: 5872 Comm: syz.0.21 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
 __might_resched+0x378/0x4d0 kernel/sched/core.c:9197
 __might_fault+0x76/0x130 mm/memory.c:7425
 store_status mm/migrate.c:2320 [inline]
 move_pages_and_store_status mm/migrate.c:2431 [inline]
 do_pages_move mm/migrate.c:2525 [inline]
 kernel_move_pages mm/migrate.c:2704 [inline]
 __do_sys_move_pages mm/migrate.c:2718 [inline]
 __se_sys_move_pages+0x1b5d/0x1c80 mm/migrate.c:2713
 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:0x7f364019ce59
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:00007f3640f79028 EFLAGS: 00000246 ORIG_RAX: 0000000000000117
RAX: ffffffffffffffda RBX: 00007f3640415fa0 RCX: 00007f364019ce59
RDX: 00002000000003c0 RSI: 0000000000000002 RDI: 0000000000000000
RBP: 00007f3640232e6f R08: 0000000000000000 R09: 0000000000000000
R10: 0000200000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f3640416038 R14: 00007f3640415fa0 R15: 00007fff4d7049e8
 </TASK>

=============================
[ BUG: Invalid wait context ]
syzkaller #0 Tainted: G        W          
-----------------------------
syz.0.21/5872 is trying to lock:
ffff88816dd71078 (&mm->mmap_lock){++++}-{4:4}, at: __might_fault+0xaf/0x130 mm/memory.c:7427
other info that might help us debug this:
context-{5:5}
1 lock held by syz.0.21/5872:
 #0: ffff88810e2682b8 (ptlock_ptr(ptdesc)){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline]
 #0: ffff88810e2682b8 (ptlock_ptr(ptdesc)){+.+.}-{3:3}, at: huge_pte_lock+0x17b/0x1e0 include/linux/hugetlb.h:1318
stack backtrace:
CPU: 0 UID: 0 PID: 5872 Comm: syz.0.21 Tainted: G        W           syzkaller #0 PREEMPT(full) 
Tainted: [W]=WARN
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_lock_invalid_wait_context kernel/locking/lockdep.c:4830 [inline]
 check_wait_context kernel/locking/lockdep.c:4902 [inline]
 __lock_acquire+0xef0/0x2e50 kernel/locking/lockdep.c:5188
 lock_acquire+0x115/0x350 kernel/locking/lockdep.c:5890
 __might_fault+0xcb/0x130 mm/memory.c:7427
 store_status mm/migrate.c:2320 [inline]
 move_pages_and_store_status mm/migrate.c:2431 [inline]
 do_pages_move mm/migrate.c:2525 [inline]
 kernel_move_pages mm/migrate.c:2704 [inline]
 __do_sys_move_pages mm/migrate.c:2718 [inline]
 __se_sys_move_pages+0x1b5d/0x1c80 mm/migrate.c:2713
 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:0x7f364019ce59
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:00007f3640f79028 EFLAGS: 00000246 ORIG_RAX: 0000000000000117
RAX: ffffffffffffffda RBX: 00007f3640415fa0 RCX: 00007f364019ce59
RDX: 00002000000003c0 RSI: 0000000000000002 RDI: 0000000000000000
RBP: 00007f3640232e6f R08: 0000000000000000 R09: 0000000000000000
R10: 0000200000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f3640416038 R14: 00007f3640415fa0 R15: 00007fff4d7049e8
 </TASK>
BUG: scheduling while atomic: syz.0.21/5872/0x00000002
INFO: lockdep is turned off.
Modules linked in:
Preemption disabled at:
[<0000000000000000>] 0x0


***

BUG: sleeping function called from invalid context in store_status

tree:      mm-new
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm.git
base:      61cccb8363fcc282d4ae0555b8739dd227f5ad0b
arch:      amd64
compiler:  Debian clang version 22.1.6 (++20260514074242+fc4aad7b5db3-1~exp1~20260514074407.73), Debian LLD 22.1.6
config:    https://ci.syzbot.org/builds/a27db994-58f5-48f4-a7f5-528b63f5a7c6/config
syz repro: https://ci.syzbot.org/findings/bd9708eb-bf3f-4bb4-acb1-82ff8e5bb3c2/syz_repro

BUG: sleeping function called from invalid context at mm/migrate.c:2320
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 5813, name: syz.1.18
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
1 lock held by syz.1.18/5813:
 #0: ffff888176f9ac78 (ptlock_ptr(ptdesc)){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline]
 #0: ffff888176f9ac78 (ptlock_ptr(ptdesc)){+.+.}-{3:3}, at: huge_pte_lock+0x17b/0x1e0 include/linux/hugetlb.h:1318
Preemption disabled at:
[<0000000000000000>] 0x0
CPU: 1 UID: 0 PID: 5813 Comm: syz.1.18 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
 __might_resched+0x378/0x4d0 kernel/sched/core.c:9197
 __might_fault+0x76/0x130 mm/memory.c:7425
 store_status+0x40/0xb0 mm/migrate.c:2320
 move_pages_and_store_status mm/migrate.c:2431 [inline]
 do_pages_move mm/migrate.c:2513 [inline]
 kernel_move_pages mm/migrate.c:2704 [inline]
 __do_sys_move_pages mm/migrate.c:2718 [inline]
 __se_sys_move_pages+0x10e4/0x1c80 mm/migrate.c:2713
 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:0x7fb06159ce59
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:00007fb062390028 EFLAGS: 00000246 ORIG_RAX: 0000000000000117
RAX: ffffffffffffffda RBX: 00007fb061815fa0 RCX: 00007fb06159ce59
RDX: 00002000000017c0 RSI: 0000000000000003 RDI: 0000000000000000
RBP: 00007fb061632e6f R08: 0000200000001840 R09: 0000000000000002
R10: 0000200000001800 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fb061816038 R14: 00007fb061815fa0 R15: 00007ffcb4b262e8
 </TASK>

=============================
[ BUG: Invalid wait context ]
syzkaller #0 Tainted: G        W          
-----------------------------
syz.1.18/5813 is trying to lock:
ffff88817695d038 (&mm->mmap_lock){++++}-{4:4}, at: __might_fault+0xaf/0x130 mm/memory.c:7427
other info that might help us debug this:
context-{5:5}
1 lock held by syz.1.18/5813:
 #0: ffff888176f9ac78 (ptlock_ptr(ptdesc)){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline]
 #0: ffff888176f9ac78 (ptlock_ptr(ptdesc)){+.+.}-{3:3}, at: huge_pte_lock+0x17b/0x1e0 include/linux/hugetlb.h:1318
stack backtrace:
CPU: 1 UID: 0 PID: 5813 Comm: syz.1.18 Tainted: G        W           syzkaller #0 PREEMPT(full) 
Tainted: [W]=WARN
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_lock_invalid_wait_context kernel/locking/lockdep.c:4830 [inline]
 check_wait_context kernel/locking/lockdep.c:4902 [inline]
 __lock_acquire+0xef0/0x2e50 kernel/locking/lockdep.c:5188
 lock_acquire+0x115/0x350 kernel/locking/lockdep.c:5890
 __might_fault+0xcb/0x130 mm/memory.c:7427
 store_status+0x40/0xb0 mm/migrate.c:2320
 move_pages_and_store_status mm/migrate.c:2431 [inline]
 do_pages_move mm/migrate.c:2513 [inline]
 kernel_move_pages mm/migrate.c:2704 [inline]
 __do_sys_move_pages mm/migrate.c:2718 [inline]
 __se_sys_move_pages+0x10e4/0x1c80 mm/migrate.c:2713
 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:0x7fb06159ce59
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:00007fb062390028 EFLAGS: 00000246 ORIG_RAX: 0000000000000117
RAX: ffffffffffffffda RBX: 00007fb061815fa0 RCX: 00007fb06159ce59
RDX: 00002000000017c0 RSI: 0000000000000003 RDI: 0000000000000000
RBP: 00007fb061632e6f R08: 0000200000001840 R09: 0000000000000002
R10: 0000200000001800 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fb061816038 R14: 00007fb061815fa0 R15: 00007ffcb4b262e8
 </TASK>
BUG: scheduling while atomic: syz.1.18/5813/0x00000002
INFO: lockdep is turned off.
Modules linked in:
Preemption disabled at:
[<0000000000000000>] 0x0


***

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.