Skip to contentSkip to conversation

page type is 0, migratetype passed is 2 (nr=256)

DISCUSSION Marc Hartmayer 5 participants 10 messages May 12, 2025 – Nov 10, 2025

Subsystems (3)
Memory management s390 Page allocator
lore
Share & tools
lore

Marc Hartmayer

author
#0 lore raw

Hi all,

In a QEMU/KVM guest with 2 vCPUs, when running a test that enables/disables a vCPU by writing 0 and 1 to the sysfs /sys/devices/system/cpu/cpu1/online in a endless loop and doing some dd operations (block size of 1MB) in the guest in parallel, I sometimes see the kernel warning:

"page type is 0, migratetype passed is 2 (nr=256)"

The first time this happened was after the warning was added with commit e0932b6c1f94 (mm: page_alloc: consolidate free page accounting").

Below is a "beautified" (via decode_stacktrace.sh) kernel stack trace (note: it's a self-compiled kernel using the debug config + Linux v6.15-rc5 + an unrelated patch on top):

```
[   31.079925] page type is 0, passed migratetype is 2 (nr=256)
[   31.079967] WARNING: CPU: 0 PID: 512 at mm/page_alloc.c:668 expand (mm/page_alloc.c:668 (discriminator 2) mm/page_alloc.c:1576 (discriminator 2))
[   31.079974] Modules linked in: essiv authenc dm_crypt encrypted_keys loop pkey_pckmo pkey diag288_wdt watchdog rng_core ghash_s390 prng aes_s390 des_s390 libdes vmw_vsock_virtio_transport vmw_vsock_virtio_transport_common vsock virtio_console vfio_ccw mdev vfio_iommu_type1 sha512_s390 sha256_s390 vfio sha1_s390 sha_common sch_fq_codel drm i2c_core drm_panel_orientation_quirks nfnetlink autofs4 ecdsa_generic ecc
[   31.080051] Hardware name: IBM 2964 NC9 702 (KVM/Linux)
[   31.080055] Krnl PSW : 0404f00180000000 000003339b22f52c expand (mm/page_alloc.c:668 (discriminator 10) mm/page_alloc.c:1576 (discriminator 10))
[   31.080064]            R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3
[   31.080071] Krnl GPRS: 0000033380000004 0000000000000005 0000000000000030 00000333ffffffff
[   31.080075]            0000000000000005 0000033380000005 0000000000000100 0000000000000008
[   31.080080]            000003339cf5e290 00000229260c99d8 ffffffff00000008 000002a8827cc000
[   31.080084]            000003ffb7d50b58 0000000000000008 000003339b22f528 000002b39be17240
[ 31.080095] Krnl Code: 000003339b22f51c: c02000936173 larl %r2,000003339c49b802

Code starting with the faulting instruction
===========================================
[   31.080095]            000003339b22f522: c0e5ffe40e37        brasl   %r14,000003339aeb1190
[   31.080095]           #000003339b22f528: af000000            mc      0,0
[   31.080095]           >000003339b22f52c: a7f4ff49            brc     15,000003339b22f3be
[   31.080095]            000003339b22f530: b904002b            lgr     %r2,%r11
[   31.080095]            000003339b22f534: c03000933a81        larl    %r3,000003339c496a36
[   31.080095]            000003339b22f53a: c0e5fffdaad3        brasl   %r14,000003339b1e4ae0
[   31.080095]            000003339b22f540: af000000            mc      0,0
[   31.080123] Call Trace:
[   31.080126] expand (mm/page_alloc.c:668 (discriminator 10) mm/page_alloc.c:1576 (discriminator 10))
[   31.080132] expand (mm/page_alloc.c:668 (discriminator 2) mm/page_alloc.c:1576 (discriminator 2))
[   31.080137] rmqueue_bulk (mm/page_alloc.c:646 mm/page_alloc.c:1592 mm/page_alloc.c:1762 mm/page_alloc.c:2315 mm/page_alloc.c:2368)
[   31.080142] __rmqueue_pcplist (mm/page_alloc.c:3090)
[   31.080147] rmqueue.isra.0 (mm/page_alloc.c:3128 mm/page_alloc.c:3159)
[   31.080153] get_page_from_freelist (mm/page_alloc.c:3687)
[   31.080158] __alloc_frozen_pages_noprof (mm/page_alloc.c:4971 (discriminator 1))
[   31.080164] alloc_pages_mpol (mm/mempolicy.c:2303 (discriminator 1))
[   31.080170] alloc_frozen_pages_noprof (mm/mempolicy.c:2374)
[   31.080176] allocate_slab (mm/slub.c:2454 mm/slub.c:2618)
[   31.080182] ___slab_alloc (mm/slub.c:2672 mm/slub.c:3858)
[   31.080187] __slab_alloc.isra.0 (mm/slub.c:3948)
[   31.080193] kmem_cache_alloc_noprof (mm/slub.c:4023 mm/slub.c:4184 mm/slub.c:4203)
[   31.080199] alloc_buffer_head (fs/buffer.c:3033)
[   31.080204] folio_alloc_buffers (fs/buffer.c:938)
[   31.080212] create_empty_buffers (fs/buffer.c:1697)
[   31.080217] __block_write_begin_int (./include/linux/pagemap.h:1025 fs/buffer.c:2134)
[   31.080222] iomap_write_begin (fs/iomap/buffered-io.c:825)
[   31.080228] iomap_write_iter (fs/iomap/buffered-io.c:952)
[   31.080234] iomap_file_buffered_write (fs/iomap/buffered-io.c:1033 (discriminator 1))
[   31.080240] blkdev_write_iter (block/fops.c:690 block/fops.c:755)
[   31.080246] vfs_write (fs/read_write.c:592 (discriminator 1) fs/read_write.c:684 (discriminator 1) fs/read_write.c:664
 (discriminator 1))
[   31.080251] ksys_write (fs/read_write.c:737)
[   31.080257] __do_syscall (arch/s390/kernel/syscall.c:125 (discriminator 2))
[   31.080262] system_call (arch/s390/kernel/entry.S:263)
[   31.080268] INFO: lockdep is turned off.
[   31.080272] Last Breaking-Event-Address:
[   31.080275] __s390_indirect_jump_r14 (arch/s390/lib/expoline.S:12)
[   31.080284] Kernel panic - not syncing: kernel: panic_on_warn set ...
[   31.080294] Hardware name: IBM 2964 NC9 702 (KVM/Linux)
[   31.080297] Call Trace:
[   31.080300] dump_stack_lvl (lib/dump_stack.c:122)
[   31.080305] panic (kernel/panic.c:372)
[   31.080310] check_panic_on_warn (kernel/panic.c:247)
[   31.080315] __warn (kernel/panic.c:751)
[   31.080321] report_bug (lib/bug.c:176 lib/bug.c:215)
[   31.080327] monitor_event_exception (arch/s390/kernel/traps.c:227 (discriminator 1))
[   31.080333] __do_pgm_check (./arch/s390/include/asm/irqflags.h:48 (discriminator 1) ./arch/s390/include/asm/irqflags.h:86 (discriminator 1) arch/s390/kernel/traps.c:347 (discriminator 1))
[   31.080338] pgm_check_handler (arch/s390/kernel/entry.S:334)
[   31.080344] expand (mm/page_alloc.c:668 (discriminator 10) mm/page_alloc.c:1576 (discriminator 10))
[   31.080349] expand (mm/page_alloc.c:668 (discriminator 2) mm/page_alloc.c:1576 (discriminator 2))
[   31.080353] rmqueue_bulk (mm/page_alloc.c:646 mm/page_alloc.c:1592 mm/page_alloc.c:1762 mm/page_alloc.c:2315 mm/page_a
lloc.c:2368)
[   31.080359] __rmqueue_pcplist (mm/page_alloc.c:3090)
[   31.080364] rmqueue.isra.0 (mm/page_alloc.c:3128 mm/page_alloc.c:3159)
[   31.080369] get_page_from_freelist (mm/page_alloc.c:3687)
[   31.080374] __alloc_frozen_pages_noprof (mm/page_alloc.c:4971 (discriminator 1))
[   31.080380] alloc_pages_mpol (mm/mempolicy.c:2303 (discriminator 1))
[   31.080385] alloc_frozen_pages_noprof (mm/mempolicy.c:2374)
[   31.080390] allocate_slab (mm/slub.c:2454 mm/slub.c:2618)
[   31.080396] ___slab_alloc (mm/slub.c:2672 mm/slub.c:3858)
[   31.080401] __slab_alloc.isra.0 (mm/slub.c:3948)
[   31.080407] kmem_cache_alloc_noprof (mm/slub.c:4023 mm/slub.c:4184 mm/slub.c:4203)
[   31.080412] alloc_buffer_head (fs/buffer.c:3033)
[   31.080417] folio_alloc_buffers (fs/buffer.c:938)
[   31.080422] create_empty_buffers (fs/buffer.c:1697)
[   31.080427] __block_write_begin_int (./include/linux/pagemap.h:1025 fs/buffer.c:2134)
[   31.080433] iomap_write_begin (fs/iomap/buffered-io.c:825)
[   31.080438] iomap_write_iter (fs/iomap/buffered-io.c:952)
[   31.080444] iomap_file_buffered_write (fs/iomap/buffered-io.c:1033 (discriminator 1))
[   31.080449] blkdev_write_iter (block/fops.c:690 block/fops.c:755)
[   31.080455] vfs_write (fs/read_write.c:592 (discriminator 1) fs/read_write.c:684 (discriminator 1) fs/read_write.c:664
 (discriminator 1))
[   31.080460] ksys_write (fs/read_write.c:737)
[   31.080465] __do_syscall (arch/s390/kernel/syscall.c:125 (discriminator 2))
[   31.080470] system_call (arch/s390/kernel/entry.S:263)
[   31.080476] INFO: lockdep is turned off.
```

Any ideas?

--
Thanks in advance,

Marc

#1 lore raw

+cc Zi

Hi Marc,

I noticed this same bug as reported in [0], but only for a _very_ recent patch series by Zi, which is only present in mm-new, which is the most unstable mm branch right now :)

So I wonder if related or a coincidence caused by something else?

This is triggered by the mm self-test (in tools/testing/selftests/mm, you can just make -jXX there) transhuge-stress, invoked as:

$ sudo ./transhuge-stress -d 20

The stack traces do look very different though so perhaps unrelated?

Cheers, Lorenzo

[0]: https://lore.kernel.org/linux-mm/[email protected]/#t

Quoted 118 lines · Marc Hartmayer

Hi all,

In a QEMU/KVM guest with 2 vCPUs, when running a test that enables/disables a vCPU by writing 0 and 1 to the sysfs /sys/devices/system/cpu/cpu1/online in a endless loop and doing some dd operations (block size of 1MB) in the guest in parallel, I sometimes see the kernel warning:

"page type is 0, migratetype passed is 2 (nr=256)"

The first time this happened was after the warning was added with commit e0932b6c1f94 (mm: page_alloc: consolidate free page accounting").

Below is a "beautified" (via decode_stacktrace.sh) kernel stack trace (note: it's a self-compiled kernel using the debug config + Linux v6.15-rc5 + an unrelated patch on top):

```
[   31.079925] page type is 0, passed migratetype is 2 (nr=256)
[   31.079967] WARNING: CPU: 0 PID: 512 at mm/page_alloc.c:668 expand (mm/page_alloc.c:668 (discriminator 2) mm/page_alloc.c:1576 (discriminator 2))
[   31.079974] Modules linked in: essiv authenc dm_crypt encrypted_keys loop pkey_pckmo pkey diag288_wdt watchdog rng_core ghash_s390 prng aes_s390 des_s390 libdes vmw_vsock_virtio_transport vmw_vsock_virtio_transport_common vsock virtio_console vfio_ccw mdev vfio_iommu_type1 sha512_s390 sha256_s390 vfio sha1_s390 sha_common sch_fq_codel drm i2c_core drm_panel_orientation_quirks nfnetlink autofs4 ecdsa_generic ecc
[   31.080051] Hardware name: IBM 2964 NC9 702 (KVM/Linux)
[   31.080055] Krnl PSW : 0404f00180000000 000003339b22f52c expand (mm/page_alloc.c:668 (discriminator 10) mm/page_alloc.c:1576 (discriminator 10))
[   31.080064]            R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3
[   31.080071] Krnl GPRS: 0000033380000004 0000000000000005 0000000000000030 00000333ffffffff
[   31.080075]            0000000000000005 0000033380000005 0000000000000100 0000000000000008
[   31.080080]            000003339cf5e290 00000229260c99d8 ffffffff00000008 000002a8827cc000
[   31.080084]            000003ffb7d50b58 0000000000000008 000003339b22f528 000002b39be17240
[ 31.080095] Krnl Code: 000003339b22f51c: c02000936173 larl %r2,000003339c49b802

Code starting with the faulting instruction
===========================================
[   31.080095]            000003339b22f522: c0e5ffe40e37        brasl   %r14,000003339aeb1190
[   31.080095]           #000003339b22f528: af000000            mc      0,0
[   31.080095]           >000003339b22f52c: a7f4ff49            brc     15,000003339b22f3be
[   31.080095]            000003339b22f530: b904002b            lgr     %r2,%r11
[   31.080095]            000003339b22f534: c03000933a81        larl    %r3,000003339c496a36
[   31.080095]            000003339b22f53a: c0e5fffdaad3        brasl   %r14,000003339b1e4ae0
[   31.080095]            000003339b22f540: af000000            mc      0,0
[   31.080123] Call Trace:
[   31.080126] expand (mm/page_alloc.c:668 (discriminator 10) mm/page_alloc.c:1576 (discriminator 10))
[   31.080132] expand (mm/page_alloc.c:668 (discriminator 2) mm/page_alloc.c:1576 (discriminator 2))
[   31.080137] rmqueue_bulk (mm/page_alloc.c:646 mm/page_alloc.c:1592 mm/page_alloc.c:1762 mm/page_alloc.c:2315 mm/page_alloc.c:2368)
[   31.080142] __rmqueue_pcplist (mm/page_alloc.c:3090)
[   31.080147] rmqueue.isra.0 (mm/page_alloc.c:3128 mm/page_alloc.c:3159)
[   31.080153] get_page_from_freelist (mm/page_alloc.c:3687)
[   31.080158] __alloc_frozen_pages_noprof (mm/page_alloc.c:4971 (discriminator 1))
[   31.080164] alloc_pages_mpol (mm/mempolicy.c:2303 (discriminator 1))
[   31.080170] alloc_frozen_pages_noprof (mm/mempolicy.c:2374)
[   31.080176] allocate_slab (mm/slub.c:2454 mm/slub.c:2618)
[   31.080182] ___slab_alloc (mm/slub.c:2672 mm/slub.c:3858)
[   31.080187] __slab_alloc.isra.0 (mm/slub.c:3948)
[   31.080193] kmem_cache_alloc_noprof (mm/slub.c:4023 mm/slub.c:4184 mm/slub.c:4203)
[   31.080199] alloc_buffer_head (fs/buffer.c:3033)
[   31.080204] folio_alloc_buffers (fs/buffer.c:938)
[   31.080212] create_empty_buffers (fs/buffer.c:1697)
[   31.080217] __block_write_begin_int (./include/linux/pagemap.h:1025 fs/buffer.c:2134)
[   31.080222] iomap_write_begin (fs/iomap/buffered-io.c:825)
[   31.080228] iomap_write_iter (fs/iomap/buffered-io.c:952)
[   31.080234] iomap_file_buffered_write (fs/iomap/buffered-io.c:1033 (discriminator 1))
[   31.080240] blkdev_write_iter (block/fops.c:690 block/fops.c:755)
[   31.080246] vfs_write (fs/read_write.c:592 (discriminator 1) fs/read_write.c:684 (discriminator 1) fs/read_write.c:664
 (discriminator 1))
[   31.080251] ksys_write (fs/read_write.c:737)
[   31.080257] __do_syscall (arch/s390/kernel/syscall.c:125 (discriminator 2))
[   31.080262] system_call (arch/s390/kernel/entry.S:263)
[   31.080268] INFO: lockdep is turned off.
[   31.080272] Last Breaking-Event-Address:
[   31.080275] __s390_indirect_jump_r14 (arch/s390/lib/expoline.S:12)
[   31.080284] Kernel panic - not syncing: kernel: panic_on_warn set ...
[   31.080294] Hardware name: IBM 2964 NC9 702 (KVM/Linux)
[   31.080297] Call Trace:
[   31.080300] dump_stack_lvl (lib/dump_stack.c:122)
[   31.080305] panic (kernel/panic.c:372)
[   31.080310] check_panic_on_warn (kernel/panic.c:247)
[   31.080315] __warn (kernel/panic.c:751)
[   31.080321] report_bug (lib/bug.c:176 lib/bug.c:215)
[   31.080327] monitor_event_exception (arch/s390/kernel/traps.c:227 (discriminator 1))
[   31.080333] __do_pgm_check (./arch/s390/include/asm/irqflags.h:48 (discriminator 1) ./arch/s390/include/asm/irqflags.h:86 (discriminator 1) arch/s390/kernel/traps.c:347 (discriminator 1))
[   31.080338] pgm_check_handler (arch/s390/kernel/entry.S:334)
[   31.080344] expand (mm/page_alloc.c:668 (discriminator 10) mm/page_alloc.c:1576 (discriminator 10))
[   31.080349] expand (mm/page_alloc.c:668 (discriminator 2) mm/page_alloc.c:1576 (discriminator 2))
[   31.080353] rmqueue_bulk (mm/page_alloc.c:646 mm/page_alloc.c:1592 mm/page_alloc.c:1762 mm/page_alloc.c:2315 mm/page_a
lloc.c:2368)
[   31.080359] __rmqueue_pcplist (mm/page_alloc.c:3090)
[   31.080364] rmqueue.isra.0 (mm/page_alloc.c:3128 mm/page_alloc.c:3159)
[   31.080369] get_page_from_freelist (mm/page_alloc.c:3687)
[   31.080374] __alloc_frozen_pages_noprof (mm/page_alloc.c:4971 (discriminator 1))
[   31.080380] alloc_pages_mpol (mm/mempolicy.c:2303 (discriminator 1))
[   31.080385] alloc_frozen_pages_noprof (mm/mempolicy.c:2374)
[   31.080390] allocate_slab (mm/slub.c:2454 mm/slub.c:2618)
[   31.080396] ___slab_alloc (mm/slub.c:2672 mm/slub.c:3858)
[   31.080401] __slab_alloc.isra.0 (mm/slub.c:3948)
[   31.080407] kmem_cache_alloc_noprof (mm/slub.c:4023 mm/slub.c:4184 mm/slub.c:4203)
[   31.080412] alloc_buffer_head (fs/buffer.c:3033)
[   31.080417] folio_alloc_buffers (fs/buffer.c:938)
[   31.080422] create_empty_buffers (fs/buffer.c:1697)
[   31.080427] __block_write_begin_int (./include/linux/pagemap.h:1025 fs/buffer.c:2134)
[   31.080433] iomap_write_begin (fs/iomap/buffered-io.c:825)
[   31.080438] iomap_write_iter (fs/iomap/buffered-io.c:952)
[   31.080444] iomap_file_buffered_write (fs/iomap/buffered-io.c:1033 (discriminator 1))
[   31.080449] blkdev_write_iter (block/fops.c:690 block/fops.c:755)
[   31.080455] vfs_write (fs/read_write.c:592 (discriminator 1) fs/read_write.c:684 (discriminator 1) fs/read_write.c:664
 (discriminator 1))
[   31.080460] ksys_write (fs/read_write.c:737)
[   31.080465] __do_syscall (arch/s390/kernel/syscall.c:125 (discriminator 2))
[   31.080470] system_call (arch/s390/kernel/entry.S:263)
[   31.080476] INFO: lockdep is turned off.
```

Any ideas?

--
Thanks in advance,

Marc

reviewer
#2 lore raw
Quoted 9 lines · Lorenzo Stoakes

+cc Zi

Hi Marc,

I noticed this same bug as reported in [0], but only for a _very_ recent patch series by Zi, which is only present in mm-new, which is the most unstable mm branch right now :)

So I wonder if related or a coincidence caused by something else?

Unless Marc's branch has my "make MIGRATE_ISOLATE a standalone bit" patchset, it should be caused by something else.

A bisect would be very helpful.

Quoted 7 lines

This is triggered by the mm self-test (in tools/testing/selftests/mm, you can just make -jXX there) transhuge-stress, invoked as:

$ sudo ./transhuge-stress -d 20

The stack traces do look very different though so perhaps unrelated?

The warning is triggered, in the both cases, a pageblock with MIGRATE_UNMOVABLE(0) is moved to MIGRATE_RECLAIMABLE(2). The pageblock is supposed to have MIGRATE_RECLAIMABLE(2) before the movement.

Quoted 124 lines

Cheers, Lorenzo

[0]: https://lore.kernel.org/linux-mm/[email protected]/#t

Quoted 118 lines · Marc Hartmayer

Hi all,

In a QEMU/KVM guest with 2 vCPUs, when running a test that enables/disables a vCPU by writing 0 and 1 to the sysfs /sys/devices/system/cpu/cpu1/online in a endless loop and doing some dd operations (block size of 1MB) in the guest in parallel, I sometimes see the kernel warning:

"page type is 0, migratetype passed is 2 (nr=256)"

The first time this happened was after the warning was added with commit e0932b6c1f94 (mm: page_alloc: consolidate free page accounting").

Below is a "beautified" (via decode_stacktrace.sh) kernel stack trace (note: it's a self-compiled kernel using the debug config + Linux v6.15-rc5 + an unrelated patch on top):

```
[   31.079925] page type is 0, passed migratetype is 2 (nr=256)
[   31.079967] WARNING: CPU: 0 PID: 512 at mm/page_alloc.c:668 expand (mm/page_alloc.c:668 (discriminator 2) mm/page_alloc.c:1576 (discriminator 2))
[   31.079974] Modules linked in: essiv authenc dm_crypt encrypted_keys loop pkey_pckmo pkey diag288_wdt watchdog rng_core ghash_s390 prng aes_s390 des_s390 libdes vmw_vsock_virtio_transport vmw_vsock_virtio_transport_common vsock virtio_console vfio_ccw mdev vfio_iommu_type1 sha512_s390 sha256_s390 vfio sha1_s390 sha_common sch_fq_codel drm i2c_core drm_panel_orientation_quirks nfnetlink autofs4 ecdsa_generic ecc
[   31.080051] Hardware name: IBM 2964 NC9 702 (KVM/Linux)
[   31.080055] Krnl PSW : 0404f00180000000 000003339b22f52c expand (mm/page_alloc.c:668 (discriminator 10) mm/page_alloc.c:1576 (discriminator 10))
[   31.080064]            R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3
[   31.080071] Krnl GPRS: 0000033380000004 0000000000000005 0000000000000030 00000333ffffffff
[   31.080075]            0000000000000005 0000033380000005 0000000000000100 0000000000000008
[   31.080080]            000003339cf5e290 00000229260c99d8 ffffffff00000008 000002a8827cc000
[   31.080084]            000003ffb7d50b58 0000000000000008 000003339b22f528 000002b39be17240
[ 31.080095] Krnl Code: 000003339b22f51c: c02000936173 larl %r2,000003339c49b802

Code starting with the faulting instruction
===========================================
[   31.080095]            000003339b22f522: c0e5ffe40e37        brasl   %r14,000003339aeb1190
[   31.080095]           #000003339b22f528: af000000            mc      0,0
[   31.080095]           >000003339b22f52c: a7f4ff49            brc     15,000003339b22f3be
[   31.080095]            000003339b22f530: b904002b            lgr     %r2,%r11
[   31.080095]            000003339b22f534: c03000933a81        larl    %r3,000003339c496a36
[   31.080095]            000003339b22f53a: c0e5fffdaad3        brasl   %r14,000003339b1e4ae0
[   31.080095]            000003339b22f540: af000000            mc      0,0
[   31.080123] Call Trace:
[   31.080126] expand (mm/page_alloc.c:668 (discriminator 10) mm/page_alloc.c:1576 (discriminator 10))
[   31.080132] expand (mm/page_alloc.c:668 (discriminator 2) mm/page_alloc.c:1576 (discriminator 2))
[   31.080137] rmqueue_bulk (mm/page_alloc.c:646 mm/page_alloc.c:1592 mm/page_alloc.c:1762 mm/page_alloc.c:2315 mm/page_alloc.c:2368)
[   31.080142] __rmqueue_pcplist (mm/page_alloc.c:3090)
[   31.080147] rmqueue.isra.0 (mm/page_alloc.c:3128 mm/page_alloc.c:3159)
[   31.080153] get_page_from_freelist (mm/page_alloc.c:3687)
[   31.080158] __alloc_frozen_pages_noprof (mm/page_alloc.c:4971 (discriminator 1))
[   31.080164] alloc_pages_mpol (mm/mempolicy.c:2303 (discriminator 1))
[   31.080170] alloc_frozen_pages_noprof (mm/mempolicy.c:2374)
[   31.080176] allocate_slab (mm/slub.c:2454 mm/slub.c:2618)
[   31.080182] ___slab_alloc (mm/slub.c:2672 mm/slub.c:3858)
[   31.080187] __slab_alloc.isra.0 (mm/slub.c:3948)
[   31.080193] kmem_cache_alloc_noprof (mm/slub.c:4023 mm/slub.c:4184 mm/slub.c:4203)
[   31.080199] alloc_buffer_head (fs/buffer.c:3033)
[   31.080204] folio_alloc_buffers (fs/buffer.c:938)
[   31.080212] create_empty_buffers (fs/buffer.c:1697)
[   31.080217] __block_write_begin_int (./include/linux/pagemap.h:1025 fs/buffer.c:2134)
[   31.080222] iomap_write_begin (fs/iomap/buffered-io.c:825)
[   31.080228] iomap_write_iter (fs/iomap/buffered-io.c:952)
[   31.080234] iomap_file_buffered_write (fs/iomap/buffered-io.c:1033 (discriminator 1))
[   31.080240] blkdev_write_iter (block/fops.c:690 block/fops.c:755)
[   31.080246] vfs_write (fs/read_write.c:592 (discriminator 1) fs/read_write.c:684 (discriminator 1) fs/read_write.c:664
 (discriminator 1))
[   31.080251] ksys_write (fs/read_write.c:737)
[   31.080257] __do_syscall (arch/s390/kernel/syscall.c:125 (discriminator 2))
[   31.080262] system_call (arch/s390/kernel/entry.S:263)
[   31.080268] INFO: lockdep is turned off.
[   31.080272] Last Breaking-Event-Address:
[   31.080275] __s390_indirect_jump_r14 (arch/s390/lib/expoline.S:12)
[   31.080284] Kernel panic - not syncing: kernel: panic_on_warn set ...
[   31.080294] Hardware name: IBM 2964 NC9 702 (KVM/Linux)
[   31.080297] Call Trace:
[   31.080300] dump_stack_lvl (lib/dump_stack.c:122)
[   31.080305] panic (kernel/panic.c:372)
[   31.080310] check_panic_on_warn (kernel/panic.c:247)
[   31.080315] __warn (kernel/panic.c:751)
[   31.080321] report_bug (lib/bug.c:176 lib/bug.c:215)
[   31.080327] monitor_event_exception (arch/s390/kernel/traps.c:227 (discriminator 1))
[   31.080333] __do_pgm_check (./arch/s390/include/asm/irqflags.h:48 (discriminator 1) ./arch/s390/include/asm/irqflags.h:86 (discriminator 1) arch/s390/kernel/traps.c:347 (discriminator 1))
[   31.080338] pgm_check_handler (arch/s390/kernel/entry.S:334)
[   31.080344] expand (mm/page_alloc.c:668 (discriminator 10) mm/page_alloc.c:1576 (discriminator 10))
[   31.080349] expand (mm/page_alloc.c:668 (discriminator 2) mm/page_alloc.c:1576 (discriminator 2))
[   31.080353] rmqueue_bulk (mm/page_alloc.c:646 mm/page_alloc.c:1592 mm/page_alloc.c:1762 mm/page_alloc.c:2315 mm/page_a
lloc.c:2368)
[   31.080359] __rmqueue_pcplist (mm/page_alloc.c:3090)
[   31.080364] rmqueue.isra.0 (mm/page_alloc.c:3128 mm/page_alloc.c:3159)
[   31.080369] get_page_from_freelist (mm/page_alloc.c:3687)
[   31.080374] __alloc_frozen_pages_noprof (mm/page_alloc.c:4971 (discriminator 1))
[   31.080380] alloc_pages_mpol (mm/mempolicy.c:2303 (discriminator 1))
[   31.080385] alloc_frozen_pages_noprof (mm/mempolicy.c:2374)
[   31.080390] allocate_slab (mm/slub.c:2454 mm/slub.c:2618)
[   31.080396] ___slab_alloc (mm/slub.c:2672 mm/slub.c:3858)
[   31.080401] __slab_alloc.isra.0 (mm/slub.c:3948)
[   31.080407] kmem_cache_alloc_noprof (mm/slub.c:4023 mm/slub.c:4184 mm/slub.c:4203)
[   31.080412] alloc_buffer_head (fs/buffer.c:3033)
[   31.080417] folio_alloc_buffers (fs/buffer.c:938)
[   31.080422] create_empty_buffers (fs/buffer.c:1697)
[   31.080427] __block_write_begin_int (./include/linux/pagemap.h:1025 fs/buffer.c:2134)
[   31.080433] iomap_write_begin (fs/iomap/buffered-io.c:825)
[   31.080438] iomap_write_iter (fs/iomap/buffered-io.c:952)
[   31.080444] iomap_file_buffered_write (fs/iomap/buffered-io.c:1033 (discriminator 1))
[   31.080449] blkdev_write_iter (block/fops.c:690 block/fops.c:755)
[   31.080455] vfs_write (fs/read_write.c:592 (discriminator 1) fs/read_write.c:684 (discriminator 1) fs/read_write.c:664
 (discriminator 1))
[   31.080460] ksys_write (fs/read_write.c:737)
[   31.080465] __do_syscall (arch/s390/kernel/syscall.c:125 (discriminator 2))
[   31.080470] system_call (arch/s390/kernel/entry.S:263)
[   31.080476] INFO: lockdep is turned off.
```

Any ideas?

--
Thanks in advance,

Marc

--
Best Regards,
Yan, Zi

reviewer
#3 lore raw
Quoted 21 lines · Zi Yan
Quoted 9 lines · Lorenzo Stoakes

+cc Zi

Hi Marc,

I noticed this same bug as reported in [0], but only for a _very_ recent patch series by Zi, which is only present in mm-new, which is the most unstable mm branch right now :)

So I wonder if related or a coincidence caused by something else?

Unless Marc's branch has my "make MIGRATE_ISOLATE a standalone bit" patchset, it should be caused by something else.

A bisect would be very helpful.

Quoted 4 lines

This is triggered by the mm self-test (in tools/testing/selftests/mm, you can just make -jXX there) transhuge-stress, invoked as:

Quoted 7 lines
Quoted 3 lines
$ sudo ./transhuge-stress -d 20

The stack traces do look very different though so perhaps unrelated?

The warning is triggered, in the both cases, a pageblock with MIGRATE_UNMOVABLE(0) is moved to MIGRATE_RECLAIMABLE(2). The pageblock is supposed to have MIGRATE_RECLAIMABLE(2) before the movement.

The weird thing is that the warning is from expand(), when the broken up chunks are put *back*. Marc, can you confirm that this is the only warning in dmesg, and there aren't any before this one?

The request does the following:

rmqueue_bulk()

    __rmqueue()
      __rmqueue_smallest()
        page_del_and_expand()
          __del_page_from_free_list()
            VM_WARN_ONCE(get_pageblock_migratetype(page) != migratetype,
                         "page type is %lu, passed migratetype is %d (nr=%d)\n",
                         get_pageblock_migratetype(page), migratetype, nr_pages);
         expand()
           __add_to_free_list()
             VM_WARN_ONCE(get_pageblock_migratetype(page) != migratetype,
                          "page type is %lu, passed migratetype is %d (nr=%d)\n",
                          get_pageblock_migratetype(page), migratetype, nr_pages);

So if only the second one triggers, but not the first one, it suggests we have a buddy page consisting of two pageblocks of different types - the first one reclaimable and the second unmovable. When we take the headpage off, the type matches. When we put the remainder from the tailblock back, it doesn't.

author
#4 lore raw
Quoted 26 lines · Johannes Weiner
Quoted 25 lines · Zi Yan
Quoted 9 lines · Lorenzo Stoakes

+cc Zi

Hi Marc,

I noticed this same bug as reported in [0], but only for a _very_ recent patch series by Zi, which is only present in mm-new, which is the most unstable mm branch right now :)

So I wonder if related or a coincidence caused by something else?

Unless Marc's branch has my "make MIGRATE_ISOLATE a standalone bit" patchset, it should be caused by something else.

A bisect would be very helpful.

Quoted 7 lines

This is triggered by the mm self-test (in tools/testing/selftests/mm, you can just make -jXX there) transhuge-stress, invoked as:

$ sudo ./transhuge-stress -d 20

The stack traces do look very different though so perhaps unrelated?

Quoted 7 lines
Quoted 3 lines

The warning is triggered, in the both cases, a pageblock with MIGRATE_UNMOVABLE(0) is moved to MIGRATE_RECLAIMABLE(2). The pageblock is supposed to have MIGRATE_RECLAIMABLE(2) before the movement.

The weird thing is that the warning is from expand(), when the broken up chunks are put *back*. Marc, can you confirm that this is the only warning in dmesg, and there aren't any before this one?

Yep, I’ve just checked, it was the first warning and panic_on_warn is set to 1.

I managed to reproduce a similar crash using 6.15.0-rc7 (this time THP seems to be involved):

…

  root@qemus390x:~# [   40.442403] ------------[ cut here ]------------
  [   40.442471] page type is 0, passed migratetype is 1 (nr=256)
  [   40.442525] WARNING: CPU: 0 PID: 350 at mm/page_alloc.c:669 expand (mm/page_alloc.c:669 (discriminator 2) mm/page_alloc.c:1572 (discriminator 2))
  [   40.442558] Modules linked in: pkey_pckmo(E) pkey(E) diag288_wdt(E) watchdog(E) s390_trng(E) virtio_console(E) rng_core(E) vmw_vsock_virtio_transport(E) vmw_vsock_virtio_transport_common(E) vsock(E) ghash_s390(E) prng(E) aes_s390(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha512_s390(E) sha256_s390(E) sha1_s390(E) sha_common(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) nfnetlink(E) autofs4(E)
  [   40.442651] Unloaded tainted modules: hmac_s390(E):1
  [   40.442677] CPU: 0 UID: 0 PID: 350 Comm: mempig_verify Tainted: G            E       6.15.0-rc7-11557-ga01c92c55b53 #1 PREEMPT
  [   40.442683] Tainted: [E]=UNSIGNED_MODULE
  [   40.442687] Hardware name: IBM 3931 A01 701 (KVM/Linux)
  [   40.442692] Krnl PSW : 0404d00180000000 000002ff929af40c expand (mm/page_alloc.c:669 (discriminator 10) mm/page_alloc.c:1572 (discriminator 10))
  [   40.442696]            R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3
  [   40.442699] Krnl GPRS: 000002ff80000004 0000000000000005 0000000000000030 0000000000000000
  [   40.442701]            0000000000000005 0000027f80000005 0000000000000100 0000000000000008
  [   40.442703]            000002ff93f99290 000001f63a415900 0000027500000008 00000275829f4000
  [   40.442704]            0000000000000000 0000000000000008 000002ff929af408 0000027f928c36f8
  [ 40.442722] Krnl Code: 000002ff929af3fc: c02000883f4b larl %r2,000002ff93ab7292

Code starting with the faulting instruction
===========================================

  [   40.442722]            000002ff929af402: c0e5ffe7bd17        brasl   %r14,000002ff926a6e30
  [   40.442722]           #000002ff929af408: af000000            mc      0,0
  [   40.442722]           >000002ff929af40c: a7f4ff49            brc     15,000002ff929af29e
  [   40.442722]            000002ff929af410: b904002b            lgr     %r2,%r11
  [   40.442722]            000002ff929af414: c03000881980        larl    %r3,000002ff93ab2714
  [   40.442722]            000002ff929af41a: c0e5fffdd883        brasl   %r14,000002ff9296a520
  [   40.442722]            000002ff929af420: af000000            mc      0,0
  [   40.442736] Call Trace:
  [   40.442738] expand (mm/page_alloc.c:669 (discriminator 10) mm/page_alloc.c:1572 (discriminator 10))
  [   40.442741] expand (mm/page_alloc.c:669 (discriminator 2) mm/page_alloc.c:1572 (discriminator 2))
  [   40.442743] rmqueue_bulk (mm/page_alloc.c:1587 mm/page_alloc.c:1758 mm/page_alloc.c:2311 mm/page_alloc.c:2364)
  [   40.442745] __rmqueue_pcplist (mm/page_alloc.c:3086)
  [   40.442748] rmqueue.isra.0 (mm/page_alloc.c:3124 mm/page_alloc.c:3155)
  [   40.442751] get_page_from_freelist (mm/page_alloc.c:3683)
  [   40.442754] __alloc_frozen_pages_noprof (mm/page_alloc.c:4967 (discriminator 1))
  [   40.442756] alloc_pages_mpol (mm/mempolicy.c:2290)
  [   40.442764] folio_alloc_mpol_noprof (mm/mempolicy.c:2322)
  [   40.442766] vma_alloc_folio_noprof (mm/mempolicy.c:2355 (discriminator 1))
  [   40.442769] vma_alloc_anon_folio_pmd (mm/huge_memory.c:1167 (discriminator 1))
  [   40.442773] __do_huge_pmd_anonymous_page (mm/huge_memory.c:1227 (discriminator 1))
  [   40.442775] __handle_mm_fault (mm/memory.c:5862 mm/memory.c:6111)
  [   40.442781] handle_mm_fault (mm/memory.c:6321)
  [   40.442783] do_exception (arch/s390/mm/fault.c:298)
  [   40.442792] __do_pgm_check (arch/s390/kernel/traps.c:345)
  [   40.442802] pgm_check_handler (arch/s390/kernel/entry.S:334)
  [   40.442805] Last Breaking-Event-Address:
  [   40.442806] __warn_printk (kernel/panic.c:801)
  [   40.442818] Kernel panic - not syncing: kernel: panic_on_warn set ...
  [   40.442822] CPU: 0 UID: 0 PID: 350 Comm: mempig_verify Tainted: G            E       6.15.0-rc7-11557-ga01c92c55b53 #1 PREEMPT
  [   40.442825] Tainted: [E]=UNSIGNED_MODULE
  [   40.442826] Hardware name: IBM 3931 A01 701 (KVM/Linux)
  [   40.442827] Call Trace:
  [   40.442828] dump_stack_lvl (lib/dump_stack.c:122)
  [   40.442831] panic (kernel/panic.c:372)
  [   40.442833] check_panic_on_warn (kernel/panic.c:247)
  [   40.442836] __warn (kernel/panic.c:751)
  [   40.443057] report_bug (lib/bug.c:176 lib/bug.c:215)
  [   40.443064] monitor_event_exception (arch/s390/kernel/traps.c:227 (discriminator 1))
  [   40.443067] __do_pgm_check (arch/s390/kernel/traps.c:345)
  [   40.443071] pgm_check_handler (arch/s390/kernel/entry.S:334)
  [   40.443074] expand (mm/page_alloc.c:669 (discriminator 10) mm/page_alloc.c:1572 (discriminator 10))
  [   40.443077] expand (mm/page_alloc.c:669 (discriminator 2) mm/page_alloc.c:1572 (discriminator 2))
  [   40.443080] rmqueue_bulk (mm/page_alloc.c:1587 mm/page_alloc.c:1758 mm/page_alloc.c:2311 mm/page_alloc.c:2364)
  [   40.443087] __rmqueue_pcplist (mm/page_alloc.c:3086)
  [   40.443090] rmqueue.isra.0 (mm/page_alloc.c:3124 mm/page_alloc.c:3155)
  [   40.443093] get_page_from_freelist (mm/page_alloc.c:3683)
  [   40.443097] __alloc_frozen_pages_noprof (mm/page_alloc.c:4967 (discriminator 1))
  [   40.443100] alloc_pages_mpol (mm/mempolicy.c:2290)
  [   40.443104] folio_alloc_mpol_noprof (mm/mempolicy.c:2322)
  [   40.443110] vma_alloc_folio_noprof (mm/mempolicy.c:2355 (discriminator 1))
  [   40.443114] vma_alloc_anon_folio_pmd (mm/huge_memory.c:1167 (discriminator 1))
  [   40.443117] __do_huge_pmd_anonymous_page (mm/huge_memory.c:1227 (discriminator 1))
  [   40.443120] __handle_mm_fault (mm/memory.c:5862 mm/memory.c:6111)
  [   40.443123] handle_mm_fault (mm/memory.c:6321)
  [   40.443126] do_exception (arch/s390/mm/fault.c:298)
  [   40.443129] __do_pgm_check (arch/s390/kernel/traps.c:345)
  [   40.443132] pgm_check_handler (arch/s390/kernel/entry.S:334)

This time, the setup is even simpler:

1. Start a 2GB QEMU/KVM guest
2. Now run some memory stress test

I run this test in a loop (with starting/shutting down the VM) and after many iterations, the bug occurs.

[…snip…]

maintainer
#5 lore raw
Quoted 1 line · Marc Hartmayer

On Mon, May 12, 2025 at 01:14 PM -0400, Johannes Weiner <[email protected]> wrote:

...

Quoted 9 lines
Quoted 3 lines

The weird thing is that the warning is from expand(), when the broken up chunks are put *back*. Marc, can you confirm that this is the only warning in dmesg, and there aren't any before this one?

Yep, I’ve just checked, it was the first warning and panic_on_warn is set to 1.

I managed to reproduce a similar crash using 6.15.0-rc7 (this time THP seems to be involved):

...

Quoted 9 lines

This time, the setup is even simpler:

1. Start a 2GB QEMU/KVM guest
2. Now run some memory stress test

I run this test in a loop (with starting/shutting down the VM) and after many iterations, the bug occurs.

[…snip…]

Hi Johannes,

Marc is going to be away for some time.
Is there any update here?

Thanks!

reviewer
#6 lore raw

Hello Alexander,

Apologies for the lack of updates. I am out myself until the 23rd. I'll dig into it when I get back if nobody beats me to it.

Thanks,
Johannes

Quoted 31 lines · On Thu, Jun 12, 2025, 11:05 Alexander Gordeev <[email protected]> wrote:
Quoted 1 line · Marc Hartmayer

On Mon, May 12, 2025 at 01:14 PM -0400, Johannes Weiner <

[email protected]> wrote:
...

Quoted 9 lines
Quoted 3 lines

The weird thing is that the warning is from expand(), when the broken up chunks are put *back*. Marc, can you confirm that this is the only warning in dmesg, and there aren't any before this one?

Yep, I’ve just checked, it was the first warning and panic_on_warn is set to 1.

I managed to reproduce a similar crash using 6.15.0-rc7 (this time THP seems to be involved):

...

Quoted 9 lines

This time, the setup is even simpler:

1. Start a 2GB QEMU/KVM guest
2. Now run some memory stress test

I run this test in a loop (with starting/shutting down the VM) and after many iterations, the bug occurs.

[…snip…]

Hi Johannes,

Marc is going to be away for some time.
Is there any update here?

Thanks!

maintainer
#7 lore raw

On Sat, Jun 14, 2025 at 10:24:32AM +0200, Johannes Weiner wrote:

Hi Johannes,

Quoted 4 lines

Hello Alexander,

Apologies for the lack of updates. I am out myself until the 23rd. I'll dig into it when I get back if nobody beats me to it.

Is there any update here?

Quoted 2 lines

Thanks,
Johannes

Thanks!

maintainer
#8 lore raw
In reply to Johannes Weiner

On Mon, May 12, 2025 at 01:14:29PM -0400, Johannes Weiner wrote:

Hi Johannes,

Quoted 50 lines · Zi Yan
Quoted 21 lines · Lorenzo Stoakes
Quoted 10 lines

+cc Zi

Hi Marc,

I noticed this same bug as reported in [0], but only for a _very_ recent patch series by Zi, which is only present in mm-new, which is the most unstable mm branch right now :)

So I wonder if related or a coincidence caused by something else?

Unless Marc's branch has my "make MIGRATE_ISOLATE a standalone bit" patchset, it should be caused by something else.

A bisect would be very helpful.

Quoted 4 lines

This is triggered by the mm self-test (in tools/testing/selftests/mm, you can just make -jXX there) transhuge-stress, invoked as:

Quoted 7 lines
Quoted 3 lines
$ sudo ./transhuge-stress -d 20

The stack traces do look very different though so perhaps unrelated?

The warning is triggered, in the both cases, a pageblock with MIGRATE_UNMOVABLE(0) is moved to MIGRATE_RECLAIMABLE(2). The pageblock is supposed to have MIGRATE_RECLAIMABLE(2) before the movement.

The weird thing is that the warning is from expand(), when the broken up chunks are put *back*. Marc, can you confirm that this is the only warning in dmesg, and there aren't any before this one?

The request does the following:

rmqueue_bulk()

    __rmqueue()
      __rmqueue_smallest()
        page_del_and_expand()
          __del_page_from_free_list()
            VM_WARN_ONCE(get_pageblock_migratetype(page) != migratetype,
                         "page type is %lu, passed migratetype is %d (nr=%d)\n",
                         get_pageblock_migratetype(page), migratetype, nr_pages);
         expand()
           __add_to_free_list()
             VM_WARN_ONCE(get_pageblock_migratetype(page) != migratetype,
                          "page type is %lu, passed migratetype is %d (nr=%d)\n",
                          get_pageblock_migratetype(page), migratetype, nr_pages);
Quoted 5 lines

So if only the second one triggers, but not the first one, it suggests we have a buddy page consisting of two pageblocks of different types - the first one reclaimable and the second unmovable. When we take the headpage off, the type matches. When we put the remainder from the tailblock back, it doesn't.

With some extra debugging added on top of 6.18-rc3 we see this:

[  388.664966] +++ __add_to_free_list(814) type 0, migratetype 1 order 8 nr 256 pid 3917 comm mempig_verify
[  388.665533] +++ __del_page_from_free_list(868) type 0, migratetype 1 order 8 nr 256 pid 3917 comm mempig_verify

Does it make sense?

Thanks!

FWIW here is the patch:

mm/page_alloc.c +18 -9
index 600d9e981c23..82b171af5b4d 100644
@@ -806,12 +806,15 @@ static inline void __add_to_free_list(struct page *page, struct zone *zone,
 				      unsigned int order, int migratetype,
 				      bool tail)
 {
+	enum migratetype pagetype = get_pageblock_migratetype(page);
 	struct free_area *area = &zone->free_area[order];
 	int nr_pages = 1 << order;
 
-	VM_WARN_ONCE(get_pageblock_migratetype(page) != migratetype,
-		     "page type is %d, passed migratetype is %d (nr=%d)\n",
-		     get_pageblock_migratetype(page), migratetype, nr_pages);
+        if (pagetype != migratetype) {
+		pr_warn("+++ %s(%d) type %d, migratetype %d order %d nr %d pid %d comm %s\n",
+			__FUNCTION__, __LINE__,
+			pagetype, migratetype, order, nr_pages, current->pid, current->comm);
+	}
 
 	if (tail)
 		list_add_tail(&page->buddy_list, &area->free_list[migratetype]);

@@ -831,13 +834,16 @@ static inline void __add_to_free_list(struct page *page, struct zone *zone,
 static inline void move_to_free_list(struct page *page, struct zone *zone,
 				     unsigned int order, int old_mt, int new_mt)
 {
+	enum migratetype pagetype = get_pageblock_migratetype(page);
 	struct free_area *area = &zone->free_area[order];
 	int nr_pages = 1 << order;
 
 	/* Free page moving can fail, so it happens before the type update */
-	VM_WARN_ONCE(get_pageblock_migratetype(page) != old_mt,
-		     "page type is %d, passed migratetype is %d (nr=%d)\n",
-		     get_pageblock_migratetype(page), old_mt, nr_pages);
+        if (pagetype != old_mt) {
+		pr_warn("+++ %s(%d) type %d, migratetype %d order %d nr %d pid %d comm %s\n",
+			__FUNCTION__, __LINE__,
+			pagetype, old_mt, order, nr_pages, current->pid, current->comm);
+	}
 
 	list_move_tail(&page->buddy_list, &area->free_list[new_mt]);
 

@@ -855,11 +861,14 @@ static inline void move_to_free_list(struct page *page, struct zone *zone,
 static inline void __del_page_from_free_list(struct page *page, struct zone *zone,
 					     unsigned int order, int migratetype)
 {
+	enum migratetype pagetype = get_pageblock_migratetype(page);
 	int nr_pages = 1 << order;
 
-        VM_WARN_ONCE(get_pageblock_migratetype(page) != migratetype,
-		     "page type is %d, passed migratetype is %d (nr=%d)\n",
-		     get_pageblock_migratetype(page), migratetype, nr_pages);
+        if (pagetype != migratetype) {
+		pr_warn("+++ %s(%d) type %d, migratetype %d order %d nr %d pid %d comm %s\n",
+			__FUNCTION__, __LINE__,
+			pagetype, migratetype, order, nr_pages, current->pid, current->comm);
+	}
 
 	/* clear reported state and update reported page count */
 	if (page_reported(page))
author
#9 lore raw
In reply to Lorenzo Stoakes
Quoted 8 lines · Lorenzo Stoakes

+cc Zi

Hi Marc,

I noticed this same bug as reported in [0], but only for a _very_ recent patch series by Zi, which is only present in mm-new, which is the most unstable mm branch right now :)

Quoted 8 lines

So I wonder if related or a coincidence caused by something else?

This is triggered by the mm self-test (in tools/testing/selftests/mm, you can just make -jXX there) transhuge-stress, invoked as:

$ sudo ./transhuge-stress -d 20

The stack traces do look very different though so perhaps unrelated?

Yep, I think it’s unrelated, but thanks for having a look!

[…snip…]