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

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

[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

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

[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?

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/ef5f6776-b405-48e8-9fa9-c56af392bc4f@lucifer.local/#t

On Mon, May 12, 2025 at 04:18:06PM +0200, Marc Hartmayer wrote:
> 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
>
>

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

[Zi Yan]

On 12 May 2025, at 12:16, Lorenzo Stoakes wrote:

> +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.

>
> 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.

>
> Cheers, Lorenzo
>
> [0]: https://lore.kernel.org/linux-mm/ef5f6776-b405-48e8-9fa9-c56af392bc4f@lucifer.local/#t
>
> On Mon, May 12, 2025 at 04:18:06PM +0200, Marc Hartmayer wrote:
>> 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

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

[Johannes Weiner]

On Mon, May 12, 2025 at 12:35:39PM -0400, Zi Yan wrote:
> On 12 May 2025, at 12:16, Lorenzo Stoakes wrote:
> 
> > +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.
> 
> >
> > 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.

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.

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

[Marc Hartmayer]

On Mon, May 12, 2025 at 01:14 PM -0400, Johannes Weiner <hannes@cmpxchg.org> wrote:
> On Mon, May 12, 2025 at 12:35:39PM -0400, Zi Yan wrote:
>> On 12 May 2025, at 12:16, Lorenzo Stoakes wrote:
>> 
>> > +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.
>> 
>> >
>> > 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.
>
> 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…]

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

[Alexander Gordeev]

On Tue, May 20, 2025 at 12:23:42PM +0200, Marc Hartmayer wrote:
> On Mon, May 12, 2025 at 01:14 PM -0400, Johannes Weiner <hannes@cmpxchg.org> wrote:
...
> > 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):
...
> 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!

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

[Johannes Weiner]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

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

On Thu, Jun 12, 2025, 11:05 Alexander Gordeev <agordeev@linux.ibm.com>
wrote:

> On Tue, May 20, 2025 at 12:23:42PM +0200, Marc Hartmayer wrote:
> > On Mon, May 12, 2025 at 01:14 PM -0400, Johannes Weiner <
> hannes@cmpxchg.org> wrote:
> ...
> > > 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):
> ...
> > 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!
>

[-- Attachment #2: Type: text/html, Size: 1852 bytes --]

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

[Alexander Gordeev]

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

Hi Johannes,

> 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?

> Thanks,
> Johannes

Thanks!

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

[Marc Hartmayer]

On Mon, May 12, 2025 at 05:16 PM +0100, Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> +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?

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

[…snip…]