[syzbot] [btrfs?] WARNING in btrfs_use_block_rsv

20 views
Skip to first unread message

syzbot

unread,
Aug 30, 2023, 6:29:57 PM8/30/23
to c...@fb.com, dst...@suse.com, jo...@toxicpanda.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com
Hello,

syzbot found the following issue on:

HEAD commit: 3b35375f19fe Merge tag 'irq-urgent-2023-08-26' of git://gi..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1156791fa80000
kernel config: https://syzkaller.appspot.com/x/.config?x=67db137b0441ab96
dashboard link: https://syzkaller.appspot.com/bug?extid=10d5b62a8d7046b86d22
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1767c1e0680000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=146903b0680000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7bc7510fe41f/non_bootable_disk-3b35375f.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/34c4f640b690/vmlinux-3b35375f.xz
kernel image: https://storage.googleapis.com/syzbot-assets/58c9c2459f41/bzImage-3b35375f.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/501d7ead33fe/mount_0.gz

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

------------[ cut here ]------------
WARNING: CPU: 1 PID: 5212 at fs/btrfs/block-rsv.c:515 btrfs_use_block_rsv+0x688/0x7f0 fs/btrfs/block-rsv.c:515
Modules linked in:
CPU: 1 PID: 5212 Comm: kworker/u17:1 Not tainted 6.5.0-rc7-syzkaller-00182-g3b35375f19fe #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Workqueue: btrfs-endio-write btrfs_work_helper
RIP: 0010:btrfs_use_block_rsv+0x688/0x7f0 fs/btrfs/block-rsv.c:515
Code: 89 ea 83 e2 07 38 d0 7f 0c 84 c0 74 08 48 89 ef e8 ed 42 47 fe 0f b6 73 5a ba e4 ff ff ff 48 c7 c7 00 e4 b7 8a e8 b8 b8 ba fd <0f> 0b e9 a3 fd ff ff e8 8c f7 f3 fd 49 8d 9d 80 04 00 00 e9 1c fb
RSP: 0018:ffffc90003737030 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff8880323ba608 RCX: 0000000000000000
RDX: ffff888029a1c4c0 RSI: ffffffff814be3c6 RDI: 0000000000000001
RBP: ffff8880323ba662 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 000000002d2d2d2d R12: 0000000000001000
R13: ffff88801fb84000 R14: 0000000000000001 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff88806b700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020d41000 CR3: 00000000219e2000 CR4: 0000000000350ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
btrfs_alloc_tree_block+0x1dd/0x1420 fs/btrfs/extent-tree.c:4883
__btrfs_cow_block+0x3ce/0x18e0 fs/btrfs/ctree.c:546
btrfs_cow_block+0x2f1/0x820 fs/btrfs/ctree.c:712
btrfs_search_slot+0x12a0/0x30e0 fs/btrfs/ctree.c:2194
btrfs_lookup_file_extent+0xcb/0x110 fs/btrfs/file-item.c:270
btrfs_drop_extents+0x433/0x2bd0 fs/btrfs/file.c:250
insert_reserved_file_extent+0x3a8/0x940 fs/btrfs/inode.c:3057
insert_ordered_extent_file_extent fs/btrfs/inode.c:3164 [inline]
btrfs_finish_one_ordered+0x1443/0x2240 fs/btrfs/inode.c:3268
btrfs_work_helper+0x20b/0xba0 fs/btrfs/async-thread.c:314
process_one_work+0xaa2/0x16f0 kernel/workqueue.c:2600
worker_thread+0x687/0x1110 kernel/workqueue.c:2751
kthread+0x33a/0x430 kernel/kthread.c:389
ret_from_fork+0x2c/0x70 arch/x86/kernel/process.c:145
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
</TASK>


---
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 bug is already fixed, 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 bug's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

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

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

syzbot

unread,
Nov 24, 2023, 9:08:10 PM11/24/23
to anand...@oracle.com, c...@fb.com, dst...@suse.com, jo...@toxicpanda.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com
syzbot has bisected this issue to:

commit a5b8a5f9f8355d27a4f8d0afa93427f16d2f3c1e
Author: Anand Jain <anand...@oracle.com>
Date: Thu Sep 28 01:09:47 2023 +0000

btrfs: support cloned-device mount capability

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1446d344e80000
start commit: d3fa86b1a7b4 Merge tag 'net-6.7-rc3' of git://git.kernel.o..
git tree: upstream
final oops: https://syzkaller.appspot.com/x/report.txt?x=1646d344e80000
console output: https://syzkaller.appspot.com/x/log.txt?x=1246d344e80000
kernel config: https://syzkaller.appspot.com/x/.config?x=6ae1a4ee971a7305
dashboard link: https://syzkaller.appspot.com/bug?extid=10d5b62a8d7046b86d22
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1431040ce80000

Reported-by: syzbot+10d5b6...@syzkaller.appspotmail.com
Fixes: a5b8a5f9f835 ("btrfs: support cloned-device mount capability")

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

Anand Jain

unread,
Nov 26, 2023, 10:38:54 AM11/26/23
to syzbot, c...@fb.com, dst...@suse.com, jo...@toxicpanda.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com
It is completely strange that this issue bisects to the commit
a5b8a5f9f835 ('btrfs: support cloned-device mount capability').
I am unable to reproduce this as well.

-------------------
WARNING: CPU: 1 PID: 58 at fs/btrfs/block-rsv.c:523
btrfs_use_block_rsv+0x60d/0x860 fs/btrfs/block-rsv.c:523
<snap>
Call Trace:
<TASK>
btrfs_alloc_tree_block+0x1e0/0x12c0 fs/btrfs/extent-tree.c:5114
btrfs_force_cow_block+0x3e5/0x19e0 fs/btrfs/ctree.c:563
btrfs_cow_block+0x2b6/0xb30 fs/btrfs/ctree.c:741
push_leaf_left+0x315/0x4d0 fs/btrfs/ctree.c:3485
split_leaf+0x9c3/0x13b0 fs/btrfs/ctree.c:3681
search_leaf fs/btrfs/ctree.c:1944 [inline]
btrfs_search_slot+0x24ba/0x2fd0 fs/btrfs/ctree.c:2131
btrfs_insert_empty_items+0xb6/0x1b0 fs/btrfs/ctree.c:4285
btrfs_insert_empty_item fs/btrfs/ctree.h:657 [inline]
insert_reserved_file_extent+0x7aa/0x950 fs/btrfs/inode.c:2907
insert_ordered_extent_file_extent fs/btrfs/inode.c:3005 [inline]
btrfs_finish_one_ordered+0x12dc/0x20d0 fs/btrfs/inode.c:3113
btrfs_work_helper+0x210/0xbf0 fs/btrfs/async-thread.c:315
process_one_work+0x886/0x15d0 kernel/workqueue.c:2630
process_scheduled_works kernel/workqueue.c:2703 [inline]
worker_thread+0x8b9/0x1290 kernel/workqueue.c:2784
kthread+0x2c6/0x3a0 kernel/kthread.c:388
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242
-----------------

btrfs_use_block_rsv()
<snap>
/*
* The global reserve still exists to save us from ourselves,
so don't
* warn_on if we are short on our delayed refs reserve.
*/
if (block_rsv->type != BTRFS_BLOCK_RSV_DELREFS &&
btrfs_test_opt(fs_info, ENOSPC_DEBUG)) {
static DEFINE_RATELIMIT_STATE(_rs,
DEFAULT_RATELIMIT_INTERVAL * 10,
/*DEFAULT_RATELIMIT_BURST*/ 1);
if (__ratelimit(&_rs))
WARN(1, KERN_DEBUG
"BTRFS: block rsv %d returned %d\n",
block_rsv->type, ret);
}
----------



Thanks, Anand

David Sterba

unread,
Nov 28, 2023, 11:47:30 AM11/28/23
to Anand Jain, syzbot, c...@fb.com, dst...@suse.com, jo...@toxicpanda.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com
On Sun, Nov 26, 2023 at 06:59:41AM +0800, Anand Jain wrote:
>
>
> On 25/11/2023 10:08, syzbot wrote:
> > syzbot has bisected this issue to:
> >
> > commit a5b8a5f9f8355d27a4f8d0afa93427f16d2f3c1e
> > Author: Anand Jain <anand...@oracle.com>
> > Date: Thu Sep 28 01:09:47 2023 +0000
> >
> > btrfs: support cloned-device mount capability
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1446d344e80000
> > start commit: d3fa86b1a7b4 Merge tag 'net-6.7-rc3' of git://git.kernel.o..
> > git tree: upstream
> > final oops: https://syzkaller.appspot.com/x/report.txt?x=1646d344e80000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1246d344e80000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=6ae1a4ee971a7305
> > dashboard link: https://syzkaller.appspot.com/bug?extid=10d5b62a8d7046b86d22
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1431040ce80000
> >
> > Reported-by: syzbot+10d5b6...@syzkaller.appspotmail.com
> > Fixes: a5b8a5f9f835 ("btrfs: support cloned-device mount capability")
> >
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
>
> It is completely strange that this issue bisects to the commit
> a5b8a5f9f835 ('btrfs: support cloned-device mount capability').
> I am unable to reproduce this as well.

I think it's because of changed timing or it can be an inconclusive
bisect. Things around space handling depend on timing, the test would
need to be run a few times to be sure.

The report provides an image so it may be good to analyze if it's scaled
properly or if the reproducer does something strange.

Aleksandr Nogikh

unread,
Nov 28, 2023, 1:09:18 PM11/28/23
to dst...@suse.cz, Anand Jain, syzbot, c...@fb.com, dst...@suse.com, jo...@toxicpanda.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com
Bisection log itself looks reasonable.

One other case to consider is that "btrfs: support cloned-device mount
capability" just helped surface the problem. Syzbot can only bisect
for the revision at which the reproducer started/stopped working and,
even though we try to minimize the reproducer (*), it may still rely
on some functionality that's not related to the actual bug. One of the
possibilities here is that the slightly changed validation rules in
btrfs_validate_super() allowed syzkaller to trigger a problem
somewhere else.

(*) We don't do it for filesystem images themselves as it does not
make very much sense -- in almost all cases by zeroing/dropping bytes
syzkaller just breaks the image and the reproducer stops working.
Without knowing the underlying fs image structure in detail it just
doesn't work as intended.

--
Aleksandr
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bug...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20231128164010.GM18929%40twin.jikos.cz.
Reply all
Reply to author
Forward
0 new messages