[syzbot] [sound?] kernel BUG in filemap_fault (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 488ef3560196 KEYS: Invert FINAL_PUT bit
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1503a10c580000
kernel config: https://syzkaller.appspot.com/x/.config?x=162faeb2d1eaefb4
dashboard link: https://syzkaller.appspot.com/bug?extid=263f159eb37a1c4c67a4
compiler: Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/10b92ce8eca6/disk-488ef356.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/4d4223a305b2/vmlinux-488ef356.xz
kernel image: https://storage.googleapis.com/syzbot-assets/b4a8f82f3ac9/bzImage-488ef356.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+263f15...@syzkaller.appspotmail.com

lookup_one_qstr_excl fs/namei.c:1711 [inline]
do_renameat2+0x470/0xc50 fs/namei.c:5234
__do_sys_rename fs/namei.c:5324 [inline]
__se_sys_rename fs/namei.c:5322 [inline]
__x64_sys_rename+0x82/0x90 fs/namei.c:5322
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
------------[ cut here ]------------
kernel BUG at mm/filemap.c:3442!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 7049 Comm: syz.2.293 Not tainted 6.16.0-rc1-syzkaller-00005-g488ef3560196 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
RIP: 0010:filemap_fault+0x117d/0x1200 mm/filemap.c:3442
Code: 38 c1 0f 8c 8e fc ff ff 4c 89 e7 e8 ad 64 29 00 e9 81 fc ff ff e8 23 18 c8 ff 48 89 df 48 c7 c6 20 30 94 8b e8 c4 a7 0d 00 90 <0f> 0b e8 0c 18 c8 ff 48 8b 3c 24 48 c7 c6 a0 36 94 8b e8 ac a7 0d
RSP: 0018:ffffc90004b073c0 EFLAGS: 00010246
RAX: f04d382b8d45cd00 RBX: ffffea0001dae580 RCX: f04d382b8d45cd00
RDX: 0000000000000000 RSI: ffffffff8db594ef RDI: ffff888027438000
RBP: ffffc90004b074f8 R08: 0000000000000003 R09: 0000000000000004
R10: dffffc0000000000 R11: fffffbfff1bfa9ec R12: dffffc0000000000
R13: 1ffffd40003b5cb1 R14: ffffea0001dae598 R15: ffffea0001dae588
FS: 00007f5736abb6c0(0000) GS:ffff888125c86000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00002000000069e2 CR3: 0000000028984000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
__do_fault+0x135/0x390 mm/memory.c:5189
do_read_fault mm/memory.c:5610 [inline]
do_fault mm/memory.c:5744 [inline]
do_pte_missing mm/memory.c:4251 [inline]
handle_pte_fault mm/memory.c:6089 [inline]
__handle_mm_fault+0x37ed/0x5620 mm/memory.c:6232
handle_mm_fault+0x2d5/0x7f0 mm/memory.c:6401
do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387
handle_page_fault arch/x86/mm/fault.c:1476 [inline]
exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623
RIP: 0010:rep_movs_alternative+0xf/0x90 arch/x86/lib/copy_user_64.S:46
Code: c4 10 c3 cc cc cc cc cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 48 83 f9 40 73 44 83 f9 08 73 25 85 c9 74 0f <8a> 06 88 07 48 ff c7 48 ff c6 48 ff c9 75 f1 e9 fd f6 03 00 66 2e
RSP: 0018:ffffc90004b07978 EFLAGS: 00050202
RAX: 00007ffffffff001 RBX: 0000000000000001 RCX: 0000000000000001
RDX: 0000000000000001 RSI: 00002000000069e2 RDI: ffff8880297ba722
RBP: 00000000000088de R08: ffff8880297ba722 R09: 1ffff110052f74e4
R10: dffffc0000000000 R11: ffffed10052f74e5 R12: 0000000000000000
R13: 0000000000000001 R14: ffff8880297ba722 R15: 00002000000069e2
copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline]
raw_copy_from_user arch/x86/include/asm/uaccess_64.h:141 [inline]
_inline_copy_from_user include/linux/uaccess.h:178 [inline]
_copy_from_user+0x7a/0xb0 lib/usercopy.c:18
copy_from_user include/linux/uaccess.h:212 [inline]
snd_rawmidi_kernel_write1+0x3ab/0x650 sound/core/rawmidi.c:1560
snd_rawmidi_write+0x5ad/0xbd0 sound/core/rawmidi.c:1629
do_loop_readv_writev fs/read_write.c:850 [inline]
vfs_writev+0x4b3/0x960 fs/read_write.c:1059
do_writev+0x14d/0x2d0 fs/read_write.c:1103
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f5735b8e929
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f5736abb038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00007f5735db5fa0 RCX: 00007f5735b8e929
RDX: 0000000000000002 RSI: 0000200000000840 RDI: 000000000000000a
RBP: 00007f5735c10b39 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f5735db5fa0 R15: 00007ffe2d0cdd08
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:filemap_fault+0x117d/0x1200 mm/filemap.c:3442
Code: 38 c1 0f 8c 8e fc ff ff 4c 89 e7 e8 ad 64 29 00 e9 81 fc ff ff e8 23 18 c8 ff 48 89 df 48 c7 c6 20 30 94 8b e8 c4 a7 0d 00 90 <0f> 0b e8 0c 18 c8 ff 48 8b 3c 24 48 c7 c6 a0 36 94 8b e8 ac a7 0d
RSP: 0018:ffffc90004b073c0 EFLAGS: 00010246
RAX: f04d382b8d45cd00 RBX: ffffea0001dae580 RCX: f04d382b8d45cd00
RDX: 0000000000000000 RSI: ffffffff8db594ef RDI: ffff888027438000
RBP: ffffc90004b074f8 R08: 0000000000000003 R09: 0000000000000004
R10: dffffc0000000000 R11: fffffbfff1bfa9ec R12: dffffc0000000000
R13: 1ffffd40003b5cb1 R14: ffffea0001dae598 R15: ffffea0001dae588
FS: 00007f5736abb6c0(0000) GS:ffff888125c86000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00002000000069e2 CR3: 0000000028984000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess), 1 bytes skipped:
0: 10 c3 adc %al,%bl
2: cc int3
3: cc int3
4: cc int3
5: cc int3
6: cc int3
7: cc int3
8: cc int3
9: cc int3
a: 90 nop
b: 90 nop
c: 90 nop
d: 90 nop
e: 90 nop
f: 90 nop
10: 90 nop
11: 90 nop
12: 90 nop
13: 90 nop
14: 90 nop
15: 90 nop
16: 90 nop
17: 90 nop
18: 90 nop
19: 90 nop
1a: 48 83 f9 40 cmp $0x40,%rcx
1e: 73 44 jae 0x64
20: 83 f9 08 cmp $0x8,%ecx
23: 73 25 jae 0x4a
25: 85 c9 test %ecx,%ecx
27: 74 0f je 0x38
* 29: 8a 06 mov (%rsi),%al <-- trapping instruction
2b: 88 07 mov %al,(%rdi)
2d: 48 ff c7 inc %rdi
30: 48 ff c6 inc %rsi
33: 48 ff c9 dec %rcx
36: 75 f1 jne 0x29
38: e9 fd f6 03 00 jmp 0x3f73a
3d: 66 data16
3e: 2e cs


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit: b4911fb0b060 Merge tag 'mmc-v6.16-rc1' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16568c8c580000
kernel config: https://syzkaller.appspot.com/x/.config?x=3f6ddf055b5c86f8
dashboard link: https://syzkaller.appspot.com/bug?extid=263f159eb37a1c4c67a4
compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=157cf48c580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=146a948c580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/5828d857f454/disk-b4911fb0.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/ecf6b7e29d2b/vmlinux-b4911fb0.xz
kernel image: https://storage.googleapis.com/syzbot-assets/cc43b227e03d/bzImage-b4911fb0.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+263f15...@syzkaller.appspotmail.com

__kasan_slab_alloc+0x22/0x80 mm/kasan/common.c:329
kasan_slab_alloc include/linux/kasan.h:250 [inline]
slab_post_alloc_hook mm/slub.c:4148 [inline]
slab_alloc_node mm/slub.c:4197 [inline]
kmem_cache_alloc_node_noprof+0x1bb/0x3c0 mm/slub.c:4249
__alloc_skb+0x112/0x2d0 net/core/skbuff.c:660
alloc_skb include/linux/skbuff.h:1336 [inline]
__ip6_append_data+0x2b8c/0x3de0 net/ipv6/ip6_output.c:1668
ip6_append_data+0x1c4/0x380 net/ipv6/ip6_output.c:1858
rawv6_sendmsg+0x124b/0x17f0 net/ipv6/raw.c:911
sock_sendmsg_nosec net/socket.c:712 [inline]
__sock_sendmsg+0x19c/0x270 net/socket.c:727
____sys_sendmsg+0x52d/0x830 net/socket.c:2566
___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620
__sys_sendmmsg+0x227/0x430 net/socket.c:2709

------------[ cut here ]------------
kernel BUG at mm/filemap.c:3442!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI

CPU: 1 UID: 0 PID: 9236 Comm: syz.3.1035 Not tainted 6.16.0-rc4-syzkaller-00049-gb4911fb0b060 #0 PREEMPT(full)

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
RIP: 0010:filemap_fault+0x117d/0x1200 mm/filemap.c:3442

Code: 38 c1 0f 8c 8e fc ff ff 4c 89 e7 e8 8d 6b 29 00 e9 81 fc ff ff e8 a3 13 c8 ff 48 89 df 48 c7 c6 a0 30 94 8b e8 d4 ae 0d 00 90 <0f> 0b e8 8c 13 c8 ff 48 8b 3c 24 48 c7 c6 20 37 94 8b e8 bc ae 0d
RSP: 0018:ffffc900030976e0 EFLAGS: 00010246
RAX: 864bab26a5780700 RBX: ffffea0001e53880 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8d96e815 RDI: 00000000ffffffff
RBP: ffffc90003097818 R08: ffffffff8f9fdbf7 R09: 1ffffffff1f3fb7e
R10: dffffc0000000000 R11: fffffbfff1f3fb7f R12: dffffc0000000000
R13: 1ffffd40003ca711 R14: ffffea0001e53898 R15: ffffea0001e53888
FS: 00007f9550ed76c0(0000) GS:ffff888125d84000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 0000200000002000 CR3: 0000000059b4a000 CR4: 00000000003526f0
Call Trace:
<TASK>
__do_fault+0x135/0x390 mm/memory.c:5169
do_shared_fault mm/memory.c:5654 [inline]
do_fault mm/memory.c:5728 [inline]
do_pte_missing mm/memory.c:4251 [inline]
handle_pte_fault mm/memory.c:6069 [inline]
__handle_mm_fault+0x198b/0x5620 mm/memory.c:6212
handle_mm_fault+0x2d5/0x7f0 mm/memory.c:6381

do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387
handle_page_fault arch/x86/mm/fault.c:1476 [inline]
exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623

RIP: 0010:__put_user_4+0xd/0x20 arch/x86/lib/putuser.S:94
Code: 66 89 01 31 c9 0f 01 ca e9 00 3b 03 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 48 89 cb 48 c1 fb 3f 48 09 d9 0f 01 cb <89> 01 31 c9 0f 01 ca e9 d7 3a 03 00 90 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffc90003097c98 EFLAGS: 00050206
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00002000000015b8
RDX: 0000000000000000 RSI: ffffffff8db5a681 RDI: ffffffff8be1b940
RBP: ffffc90003097eb0 R08: 0000000000000000 R09: ffffffff820a3bc0
R10: dffffc0000000000 R11: ffffed100b371081 R12: 0000200000001580
R13: 0000000000040000 R14: 0000200000000480 R15: 0000000000000044
__sys_sendmmsg+0x25f/0x430 net/socket.c:2714
__do_sys_sendmmsg net/socket.c:2736 [inline]
__se_sys_sendmmsg net/socket.c:2733 [inline]
__x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733

do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

RIP: 0033:0x7f954ff8e929

Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48

RSP: 002b:00007f9550ed7038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
RAX: ffffffffffffffda RBX: 00007f95501b5fa0 RCX: 00007f954ff8e929
RDX: 00000000000002e9 RSI: 0000200000000480 RDI: 0000000000000004
RBP: 00007f9550010b39 R08: 0000000000000000 R09: 0000000000000000

R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000

R13: 0000000000000000 R14: 00007f95501b5fa0 R15: 00007ffcd704c578

</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:filemap_fault+0x117d/0x1200 mm/filemap.c:3442

Code: 38 c1 0f 8c 8e fc ff ff 4c 89 e7 e8 8d 6b 29 00 e9 81 fc ff ff e8 a3 13 c8 ff 48 89 df 48 c7 c6 a0 30 94 8b e8 d4 ae 0d 00 90 <0f> 0b e8 8c 13 c8 ff 48 8b 3c 24 48 c7 c6 20 37 94 8b e8 bc ae 0d
RSP: 0018:ffffc900030976e0 EFLAGS: 00010246
RAX: 864bab26a5780700 RBX: ffffea0001e53880 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8d96e815 RDI: 00000000ffffffff
RBP: ffffc90003097818 R08: ffffffff8f9fdbf7 R09: 1ffffffff1f3fb7e
R10: dffffc0000000000 R11: fffffbfff1f3fb7f R12: dffffc0000000000
R13: 1ffffd40003ca711 R14: ffffea0001e53898 R15: ffffea0001e53888
FS: 00007f9550ed76c0(0000) GS:ffff888125d84000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 0000200000002000 CR3: 0000000059b4a000 CR4: 00000000003526f0
----------------
Code disassembly (best guess):
0: 66 89 01 mov %ax,(%rcx)
3: 31 c9 xor %ecx,%ecx
5: 0f 01 ca clac
8: e9 00 3b 03 00 jmp 0x33b0d

d: 90 nop
e: 90 nop
f: 90 nop
10: 90 nop
11: 90 nop
12: 90 nop
13: 90 nop
14: 90 nop
15: 90 nop
16: 90 nop
17: 90 nop
18: 90 nop
19: 90 nop

1a: 90 nop
1b: 90 nop
1c: 90 nop
1d: 48 89 cb mov %rcx,%rbx
20: 48 c1 fb 3f sar $0x3f,%rbx
24: 48 09 d9 or %rbx,%rcx
27: 0f 01 cb stac
* 2a: 89 01 mov %eax,(%rcx) <-- trapping instruction
2c: 31 c9 xor %ecx,%ecx
2e: 0f 01 ca clac
31: e9 d7 3a 03 00 jmp 0x33b0d
36: 90 nop
37: 90 nop
38: 90 nop
39: 90 nop
3a: 90 nop
3b: 90 nop
3c: 90 nop
3d: 90 nop
3e: 90 nop
3f: 90 nop


---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

[Hillf Danton]

> Date: Thu, 03 Jul 2025 09:43:30 -0700

> syzbot has found a reproducer for the following issue on:
>
> HEAD commit: b4911fb0b060 Merge tag 'mmc-v6.16-rc1' of git://git.kernel..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=16568c8c580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=3f6ddf055b5c86f8
> dashboard link: https://syzkaller.appspot.com/bug?extid=263f159eb37a1c4c67a4

> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=157cf48c580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=146a948c580000

#syz test

--- x/mm/filemap.c
+++ y/mm/filemap.c
@@ -3439,7 +3439,6 @@ retry_find:
folio_put(folio);
goto retry_find;
}
- VM_BUG_ON_FOLIO(!folio_contains(folio, index), folio);

/*
* We have a locked folio in the page cache, now we need to check
@@ -3490,6 +3489,7 @@ retry_find:
return VM_FAULT_SIGBUS;
}

+ VM_BUG_ON_FOLIO(!folio_contains(folio, index), folio);
vmf->page = folio_file_page(folio, index);
return ret | VM_FAULT_LOCKED;

--

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+263f15...@syzkaller.appspotmail.com
Tested-by: syzbot+263f15...@syzkaller.appspotmail.com

Tested on:

commit: 4c06e63b Merge tag 'for-6.16-rc4-tag' of git://git.ker..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13768582580000

kernel config: https://syzkaller.appspot.com/x/.config?x=3f6ddf055b5c86f8
dashboard link: https://syzkaller.appspot.com/bug?extid=263f159eb37a1c4c67a4

compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7

patch: https://syzkaller.appspot.com/x/patch.diff?x=169df770580000

Note: testing is done by a robot and is best-effort only.

[syzbot]

syzbot suspects this issue was fixed by commit:

commit bdb86f6b87633cc020f8225ae09d336da7826724
Author: Ryan Roberts <ryan.r...@arm.com>
Date: Mon Jun 9 09:27:23 2025 +0000

mm/readahead: honour new_order in page_cache_ra_order()

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1100b934580000
start commit: b4911fb0b060 Merge tag 'mmc-v6.16-rc1' of git://git.kernel..
git tree: upstream

kernel config: https://syzkaller.appspot.com/x/.config?x=3f6ddf055b5c86f8
dashboard link: https://syzkaller.appspot.com/bug?extid=263f159eb37a1c4c67a4

syz repro: https://syzkaller.appspot.com/x/repro.syz?x=157cf48c580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=146a948c580000

If the result looks correct, please mark the issue as fixed by replying with:

#syz fix: mm/readahead: honour new_order in page_cache_ra_order()

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

[Ryan Roberts]

On 14/09/2025 11:51, syzbot wrote:
> syzbot suspects this issue was fixed by commit:
>
> commit bdb86f6b87633cc020f8225ae09d336da7826724
> Author: Ryan Roberts <ryan.r...@arm.com>
> Date: Mon Jun 9 09:27:23 2025 +0000
>
> mm/readahead: honour new_order in page_cache_ra_order()

I'm not sure what original bug you are claiming this is fixing? Perhaps this?

https://lore.kernel.org/linux-mm/6852b77e.a70a022...@google.com/

If so, the fix for that was squashed into the original patch before it was
merged upstream. That is now Commit 38b0ece6d763 ("mm/filemap: allow arch to
request folio size for exec memory").

Thanks,
Ryan

[Jan Kara]

On Tue 16-09-25 13:50:08, Ryan Roberts wrote:
> On 14/09/2025 11:51, syzbot wrote:
> > syzbot suspects this issue was fixed by commit:
> >
> > commit bdb86f6b87633cc020f8225ae09d336da7826724
> > Author: Ryan Roberts <ryan.r...@arm.com>
> > Date: Mon Jun 9 09:27:23 2025 +0000
> >
> > mm/readahead: honour new_order in page_cache_ra_order()
>
> I'm not sure what original bug you are claiming this is fixing? Perhaps this?
>
> https://lore.kernel.org/linux-mm/6852b77e.a70a022...@google.com/

I think it was:

https://lore.kernel.org/all/684ffc59.a00a022...@google.com/

at least that's what the syzbot email replies to... And it doesn't make a
lot of sense but it isn't totally off either. So I'd just let the syzbot
bug autoclose after some timeout.

Honza
--
Jan Kara <ja...@suse.com>
SUSE Labs, CR

[David Hildenbrand]

Hm, in the issue we ran into was:

VM_BUG_ON_FOLIO(!folio_contains(folio, index), folio);

in filemap_fault().

Now, that sounds rather bad, especially given that it was reported upstream.

So likely we should figure out what happened and see if it really fixed
it and if so, why it fixed it (stable backports etc)?

Could be that Ryans patch is just making the problem harder to
reproduce, of course (what I assume right now).


Essentially we do a

folio = filemap_get_folio(mapping, index);

followed by

if (!lock_folio_maybe_drop_mmap(vmf, folio, &fpin))
goto out_retry;

/* Did it get truncated? */
if (unlikely(folio->mapping != mapping)) {
folio_unlock(folio);
folio_put(folio);
goto retry_find;
}
VM_BUG_ON_FOLIO(!folio_contains(folio, index), folio);


I would assume that if !folio_contains(folio, index), either the folio
got split in the meantime (filemap_get_folio() returned with a raised
reference, though) or that file pagecache contained something wrong.


In __filemap_get_folio() we perform the same checks after locking the
folio (with FGP_LOCK), and weird enough it didn't trigger yet there.

--
Cheers

David / dhildenb

[Jan Kara]

On Wed 17-09-25 09:57:19, David Hildenbrand wrote:
> On 16.09.25 15:05, Jan Kara wrote:
> > On Tue 16-09-25 13:50:08, Ryan Roberts wrote:
> > > On 14/09/2025 11:51, syzbot wrote:
> > > > syzbot suspects this issue was fixed by commit:
> > > >
> > > > commit bdb86f6b87633cc020f8225ae09d336da7826724
> > > > Author: Ryan Roberts <ryan.r...@arm.com>
> > > > Date: Mon Jun 9 09:27:23 2025 +0000
> > > >
> > > > mm/readahead: honour new_order in page_cache_ra_order()
> > >
> > > I'm not sure what original bug you are claiming this is fixing? Perhaps this?
> > >
> > > https://lore.kernel.org/linux-mm/6852b77e.a70a022...@google.com/
> >
> > I think it was:
> >
> > https://lore.kernel.org/all/684ffc59.a00a022...@google.com/
> >
> > at least that's what the syzbot email replies to... And it doesn't make a
> > lot of sense but it isn't totally off either. So I'd just let the syzbot
> > bug autoclose after some timeout.
>
> Hm, in the issue we ran into was:
>
> VM_BUG_ON_FOLIO(!folio_contains(folio, index), folio);
>
> in filemap_fault().
>
> Now, that sounds rather bad, especially given that it was reported upstream.
>
> So likely we should figure out what happened and see if it really fixed it
> and if so, why it fixed it (stable backports etc)?

Ok, ok, fair enough ;)

> Could be that Ryans patch is just making the problem harder to reproduce, of
> course (what I assume right now).
>
> Essentially we do a
>
> folio = filemap_get_folio(mapping, index);
>
> followed by
>
> if (!lock_folio_maybe_drop_mmap(vmf, folio, &fpin))
> goto out_retry;
>
> /* Did it get truncated? */
> if (unlikely(folio->mapping != mapping)) {
> folio_unlock(folio);
> folio_put(folio);
> goto retry_find;
> }
> VM_BUG_ON_FOLIO(!folio_contains(folio, index), folio);
>
>
> I would assume that if !folio_contains(folio, index), either the folio got
> split in the meantime (filemap_get_folio() returned with a raised reference,
> though) or that file pagecache contained something wrong.

Right.

> In __filemap_get_folio() we perform the same checks after locking the folio
> (with FGP_LOCK), and weird enough it didn't trigger yet there.

But we don't call __filemap_get_folio() with FGP_LOCK from filemap_fault().
The folio locking is handled by lock_folio_maybe_drop_mmap() as you
mentioned. So this is the first time we do the assert after getting the
folio AFAICT. So some race with folio split looks plausible. Checking the
reproducer it does play with mmap(2) and madvise(MADV_REMOVE) over the
mapped range so the page fault may be racing with
truncate_inode_partial_folio()->try_folio_split(). But I don't see the race
there now...

[David Hildenbrand]

>>
>> if (!lock_folio_maybe_drop_mmap(vmf, folio, &fpin))
>> goto out_retry;
>>
>> /* Did it get truncated? */
>> if (unlikely(folio->mapping != mapping)) {
>> folio_unlock(folio);
>> folio_put(folio);
>> goto retry_find;
>> }
>> VM_BUG_ON_FOLIO(!folio_contains(folio, index), folio);
>>
>>
>> I would assume that if !folio_contains(folio, index), either the folio got
>> split in the meantime (filemap_get_folio() returned with a raised reference,
>> though) or that file pagecache contained something wrong.
>
> Right.
>
>> In __filemap_get_folio() we perform the same checks after locking the folio
>> (with FGP_LOCK), and weird enough it didn't trigger yet there.
>
> But we don't call __filemap_get_folio() with FGP_LOCK from filemap_fault().

Yes. I should have clarified that we haven't seen the VM_BUG_ON_FOLIO()
trigger on other callpaths that set FGP_LOCK, because I would think the
very same problem could happen there as well.

> The folio locking is handled by lock_folio_maybe_drop_mmap() as you
> mentioned. So this is the first time we do the assert after getting the
> folio AFAICT. So some race with folio split looks plausible. Checking the
> reproducer it does play with mmap(2) and madvise(MADV_REMOVE) over the
> mapped range so the page fault may be racing with
> truncate_inode_partial_folio()->try_folio_split(). But I don't see the race
> there now...

__filemap_get_folio() will grab a reference and verify that the xarray
didn't change. So having a concurrent split succeed would be weird,
because freezing the refcount should fail. Of course, some refcounting
inconsistency could trigger something weird like that.

I can spot that we are also manually calling
__filemap_get_folio(FGP_CREAT|FGP_FOR_MMAP) on the else path if
filemap_get_folio() failed, maybe that's the problematic bit (and maybe
that's where readahead logic makes a difference).

[syzbot]

Auto-closing this bug as obsolete.
No recent activity, existing reproducers are no longer triggering the issue.