[syzbot] [btrfs?] kernel BUG in scrub_stripe_get_kaddr

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 262858079afd Add linux-next specific files for 20250926
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1562cae2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=6117d7eea7e1f3a7
dashboard link: https://syzkaller.appspot.com/bug?extid=bde59221318c592e6346
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=137abf12580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1277f142580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/818c8ba6ac53/disk-26285807.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/da143e1d7f10/vmlinux-26285807.xz
kernel image: https://storage.googleapis.com/syzbot-assets/b73ae95dc148/bzImage-26285807.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/27e0b3290872/mount_1.gz
fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=1477f142580000)

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

BTRFS info (device loop0): force clearing of disk cache
BTRFS info (device loop0): enabling auto defrag
BTRFS info (device loop0): max_inline set to 0
BTRFS info (device loop0): scrub: started on devid 1
assertion failed: !folio_test_partial_kmap(folio) :: 0, in fs/btrfs/scrub.c:697
------------[ cut here ]------------
kernel BUG at fs/btrfs/scrub.c:697!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 6077 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
RIP: 0010:scrub_stripe_get_kaddr+0x1bb/0x1c0 fs/btrfs/scrub.c:697
Code: 0f 0b e8 b8 14 db fd 48 c7 c7 60 8d ef 8b 48 c7 c6 a0 9f ef 8b 31 d2 48 c7 c1 20 8e ef 8b 41 b8 b9 02 00 00 e8 86 58 42 fd 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3
RSP: 0018:ffffc9000354f0d0 EFLAGS: 00010246
RAX: 000000000000004f RBX: ffff88805bfa0010 RCX: f481606445f80d00
RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
RBP: 000000000000000c R08: ffffc9000354ede7 R09: 1ffff920006a9dbc
R10: dffffc0000000000 R11: fffff520006a9dbd R12: dffffc0000000000
R13: dffffc0000000000 R14: ffff88805bfa0010 R15: 000000000000000c
FS: 000055556411a500(0000) GS:ffff8881259fc000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f34bfdf2b60 CR3: 000000007537c000 CR4: 00000000003526f0
Call Trace:
<TASK>
scrub_bio_add_sector fs/btrfs/scrub.c:932 [inline]
scrub_submit_initial_read+0xf21/0x1120 fs/btrfs/scrub.c:1897
submit_initial_group_read+0x423/0x5b0 fs/btrfs/scrub.c:1952
flush_scrub_stripes+0x18f/0x1150 fs/btrfs/scrub.c:1973
scrub_stripe+0xbea/0x2a30 fs/btrfs/scrub.c:2516
scrub_chunk+0x2a3/0x430 fs/btrfs/scrub.c:2575
scrub_enumerate_chunks+0xa70/0x1350 fs/btrfs/scrub.c:2839
btrfs_scrub_dev+0x6e7/0x10e0 fs/btrfs/scrub.c:3153
btrfs_ioctl_scrub+0x249/0x4b0 fs/btrfs/ioctl.c:3163
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f2f5d78eec9
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:00007ffef70163e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f2f5d9e5fa0 RCX: 00007f2f5d78eec9
RDX: 0000200000000000 RSI: 00000000c400941b RDI: 0000000000000004
RBP: 00007f2f5d811f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f2f5d9e5fa0 R14: 00007f2f5d9e5fa0 R15: 0000000000000003
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:scrub_stripe_get_kaddr+0x1bb/0x1c0 fs/btrfs/scrub.c:697
Code: 0f 0b e8 b8 14 db fd 48 c7 c7 60 8d ef 8b 48 c7 c6 a0 9f ef 8b 31 d2 48 c7 c1 20 8e ef 8b 41 b8 b9 02 00 00 e8 86 58 42 fd 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3
RSP: 0018:ffffc9000354f0d0 EFLAGS: 00010246
RAX: 000000000000004f RBX: ffff88805bfa0010 RCX: f481606445f80d00
RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
RBP: 000000000000000c R08: ffffc9000354ede7 R09: 1ffff920006a9dbc
R10: dffffc0000000000 R11: fffff520006a9dbd R12: dffffc0000000000
R13: dffffc0000000000 R14: ffff88805bfa0010 R15: 000000000000000c
FS: 000055556411a500(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000556796dbd950 CR3: 000000007537c000 CR4: 00000000003526f0


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

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

[Qu Wenruo]

在 2025/9/30 05:15, syzbot 写道:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 262858079afd Add linux-next specific files for 20250926
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1562cae2580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=6117d7eea7e1f3a7
> dashboard link: https://syzkaller.appspot.com/bug?extid=bde59221318c592e6346
> compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=137abf12580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1277f142580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/818c8ba6ac53/disk-26285807.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/da143e1d7f10/vmlinux-26285807.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/b73ae95dc148/bzImage-26285807.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/27e0b3290872/mount_1.gz
> fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=1477f142580000)
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+bde592...@syzkaller.appspotmail.com
>
> BTRFS info (device loop0): force clearing of disk cache
> BTRFS info (device loop0): enabling auto defrag
> BTRFS info (device loop0): max_inline set to 0
> BTRFS info (device loop0): scrub: started on devid 1
> assertion failed: !folio_test_partial_kmap(folio) :: 0, in fs/btrfs/scrub.c:697

This is caused by the config CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y, which
forces every folio_test_partial_kmap() to always return true.

I'm not sure how this config would help in the real world, especially
for cases where we can control the folio being allocated, and on 64bits
systems where kmap_local*() is just no-op.

Anyway I'll change all those folio_test_partial_kmap() usages in
ASSERT()s to folio_test_highmem() directly.

Thanks,
Qu