Re: [syzbot] [mm?] kernel BUG in try_to_unmap_one

[David Hildenbrand <david@redhat.com>]

On 02.03.25 00:40, Hillf Danton wrote:
> On Sat, 01 Mar 2025 14:41:20 -0800
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit:    e5d3fd687aac Add linux-next specific files for 20250218
>> git tree:       linux-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=12faf7f8580000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=4e945b2fe8e5992f
>> dashboard link: https://syzkaller.appspot.com/bug?extid=fb86166504f57eff29d7
>> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
>>
>> Unfortunately, I don't have any reproducer for this issue yet.
>>
>> Downloadable assets:
>> disk image: https://storage.googleapis.com/syzbot-assets/ef079ccd2725/disk-e5d3fd68.raw.xz
>> vmlinux: https://storage.googleapis.com/syzbot-assets/99f2123d6831/vmlinux-e5d3fd68.xz
>> kernel image: https://storage.googleapis.com/syzbot-assets/eadfc9520358/bzImage-e5d3fd68.xz
>>
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: syzbot+fb86166504f57eff29d7@syzkaller.appspotmail.com
>>
>>   evict+0x4e8/0x9a0 fs/inode.c:806
>>   __dentry_kill+0x20d/0x630 fs/dcache.c:660
>>   dput+0x19f/0x2b0 fs/dcache.c:902
>>   __fput+0x60b/0x9f0 fs/file_table.c:472
>>   task_work_run+0x24f/0x310 kernel/task_work.c:227
>>   resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
>>   exit_to_user_mode_loop kernel/entry/common.c:114 [inline]
>>   exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]
>>   __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
>>   syscall_exit_to_user_mode+0x13f/0x340 kernel/entry/common.c:218
>>   do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89
>>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
>> ------------[ cut here ]------------
>> kernel BUG at mm/rmap.c:1858!
>> Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
>> CPU: 1 UID: 0 PID: 6053 Comm: syz.4.27 Not tainted 6.14.0-rc3-next-20250218-syzkaller #0
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
>> RIP: 0010:try_to_unmap_one+0x3d0d/0x3fa0 mm/rmap.c:1858
>> Code: c7 c7 80 93 c3 8e 48 89 da e8 ef f3 19 03 e9 68 ca ff ff e8 b5 12 ab ff 48 8b 7c 24 20 48 c7 c6 80 17 36 8c e8 94 d2 f5 ff 90 <0f> 0b e8 9c 12 ab ff 48 8b 7c 24 18 48 c7 c6 40 1c 36 8c e8 7b d2
>> RSP: 0018:ffffc9000b1be9c0 EFLAGS: 00010246
>> RAX: 367eb4645686ad00 RBX: 00000000f4000000 RCX: ffffc9000b1be503
>> RDX: 0000000000000004 RSI: ffffffff8c2aaf60 RDI: ffffffff8c8156e0
>> RBP: ffffc9000b1bedf0 R08: ffffffff903da477 R09: 1ffffffff207b48e
>> R10: dffffc0000000000 R11: fffffbfff207b48f R12: 8000000053c008e7
>> R13: dffffc0000000000 R14: ffffea00014f0000 R15: ffffea00014f0030
>> FS:  00007f4d2783e6c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 000000110c465fa1 CR3: 000000002a1f6000 CR4: 00000000003526f0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> Call Trace:
>>   <TASK>
>>   __rmap_walk_file+0x420/0x5f0 mm/rmap.c:2774
>>   try_to_unmap+0x219/0x2e0
>>   unmap_folio+0x183/0x1f0 mm/huge_memory.c:3053
>>   __folio_split+0x849/0x16d0 mm/huge_memory.c:3696
>>   truncate_inode_partial_folio+0x9b1/0xdc0 mm/truncate.c:234
>>   shmem_undo_range+0x82f/0x1820 mm/shmem.c:1143
> 
> Given folio_test_hugetlb(folio) [1], what is weird is hugetlb page in a
> shmem mapping.
> 

Right, the problem begins when we call __folio_split() on a hugetlb 
folio, and the issue is that we seem to find that in the pagecache.

I wonder if there is some weird interaction with out recent folio split 
changes in next. Maybe, for some reason, we end up adding a wrong folio 
to the pagecache during a split (truncation), and a follow-up split 
(truncation) finds the wrong folio.

Just a guess, though. CCing Zi Yan.

-- 
Cheers,

David / dhildenb