[syzbot] [btrfs?] WARNING in __btrfs_update_delayed_inode (4)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: bea8d77e45a8 Merge tag 'staging-7.1-rc1' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1636202a580000
kernel config: https://syzkaller.appspot.com/x/.config?x=f8c5ce991a39e5d9
dashboard link: https://syzkaller.appspot.com/bug?extid=768687d6d7c96a124e24
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8

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

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-bea8d77e.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/fa29d85c34c6/vmlinux-bea8d77e.xz
kernel image: https://storage.googleapis.com/syzbot-assets/c65a4276191b/bzImage-bea8d77e.xz

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

------------[ cut here ]------------
BTRFS: Transaction aborted (error -28)
WARNING: fs/btrfs/delayed-inode.c:1027 at __btrfs_update_delayed_inode+0xe3d/0x1070 fs/btrfs/delayed-inode.c:1027, CPU#0: kworker/u4:5/70
Modules linked in:
CPU: 0 UID: 0 PID: 70 Comm: kworker/u4:5 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:__btrfs_update_delayed_inode+0xe40/0x1070 fs/btrfs/delayed-inode.c:1027
Code: bc bd fd e9 22 01 00 00 e8 7d d1 a2 fd 84 c0 74 23 e8 a4 bc bd fd e9 0f 01 00 00 e8 9a bc bd fd 48 8d 3d 63 e8 34 0c 44 89 ee <67> 48 0f b9 3a e9 31 01 00 00 e8 51 38 b1 07 89 c3 31 ff 89 c6 e8
RSP: 0018:ffffc90000cff140 EFLAGS: 00010293
RAX: ffffffff84082226 RBX: 00000000ffffffe4 RCX: ffff888000bc4a00
RDX: 0000000000000000 RSI: 00000000ffffffe4 RDI: ffffffff903d0a90
RBP: ffffc90000cff270 R08: ffff888000bc4a00 R09: 0000000000000003
R10: 00000000fffffffb R11: 0000000000000000 R12: ffff888011cf9200
R13: 00000000ffffffe4 R14: 0000000000000000 R15: ffff888012ef93c0
FS: 0000000000000000(0000) GS:ffff88808c812000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4b4adeaff8 CR3: 000000001f399000 CR4: 0000000000352ef0
Call Trace:
<TASK>
btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1103 [inline]
__btrfs_commit_inode_delayed_items+0x1dfa/0x1f50 fs/btrfs/delayed-inode.c:1127
__btrfs_run_delayed_items+0x1f6/0x510 fs/btrfs/delayed-inode.c:1158
btrfs_commit_transaction+0x836/0x30e0 fs/btrfs/transaction.c:2376
flush_space+0x2a3/0xe20 fs/btrfs/space-info.c:-1
do_async_reclaim_data_space+0x29a/0x520 fs/btrfs/space-info.c:1464
btrfs_async_reclaim_data_space+0x41/0x90 fs/btrfs/space-info.c:1512
process_one_work kernel/workqueue.c:3302 [inline]
process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3385
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3466
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
----------------
Code disassembly (best guess):
0: bc bd fd e9 22 mov $0x22e9fdbd,%esp
5: 01 00 add %eax,(%rax)
7: 00 e8 add %ch,%al
9: 7d d1 jge 0xffffffdc
b: a2 fd 84 c0 74 23 e8 movabs %al,0xbca4e82374c084fd
12: a4 bc
14: bd fd e9 0f 01 mov $0x10fe9fd,%ebp
19: 00 00 add %al,(%rax)
1b: e8 9a bc bd fd call 0xfdbdbcba
20: 48 8d 3d 63 e8 34 0c lea 0xc34e863(%rip),%rdi # 0xc34e88a
27: 44 89 ee mov %r13d,%esi
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: e9 31 01 00 00 jmp 0x165
34: e8 51 38 b1 07 call 0x7b1388a
39: 89 c3 mov %eax,%ebx
3b: 31 ff xor %edi,%edi
3d: 89 c6 mov %eax,%esi
3f: e8 .byte 0xe8


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

[ar...@linux.intel.com]

From: Arjan van de Ven <ar...@linux.intel.com>

On Fri, 24 Apr 2026 00:54:32 -0700
syzbot <syzbot+768687...@syzkaller.appspotmail.com> wrote:

> WARNING: fs/btrfs/delayed-inode.c:1027 at
> __btrfs_update_delayed_inode+0xe3d/0x1070

Analyzed this WARNING; here are the findings.

Decoded backtrace source listings
----------------------------------

--- __btrfs_update_delayed_inode (crash site, fs/btrfs/delayed-inode.c:1027) ---

996 static int __btrfs_update_delayed_inode(struct btrfs_trans_handle *trans,
997 struct btrfs_root *root,
998 struct btrfs_path *path,
999 struct btrfs_delayed_node *node)
1000 {
1001 struct btrfs_fs_info *fs_info = root->fs_info;
1002 struct btrfs_key key;
1003 struct btrfs_inode_item *inode_item;
1004 struct extent_buffer *leaf;
1005 int mod;
1006 int ret;
...
1012 if (test_bit(BTRFS_DELAYED_NODE_DEL_IREF, &node->flags))
1013 mod = -1;
1014 else
1015 mod = 1;
1016
1017 ret = btrfs_lookup_inode(trans, root, path, &key, mod); // returns -28 (-ENOSPC)
1018 if (ret > 0)
1019 ret = -ENOENT;
1020 if (ret < 0) {
1021 /*
1022 * If we fail to update the delayed inode we need to abort the
1023 * transaction, because we could leave the inode with the
1024 * improper counts behind.
1025 */
1026 if (unlikely(ret != -ENOENT))
1027 btrfs_abort_transaction(trans, ret); // <- WARNING fires here
1028 goto out;
1029 }
...
1088 }

--- btrfs_update_delayed_inode (inlined, fs/btrfs/delayed-inode.c:1103) ---

1090 static inline int btrfs_update_delayed_inode(struct btrfs_trans_handle *trans,
1091 struct btrfs_root *root,
1092 struct btrfs_path *path,
1093 struct btrfs_delayed_node *node)
1094 {
1095 int ret;
1096
1097 mutex_lock(&node->mutex);
1098 if (!test_bit(BTRFS_DELAYED_NODE_INODE_DIRTY, &node->flags)) {
1099 mutex_unlock(&node->mutex);
1100 return 0;
1101 }
1102
1103 ret = __btrfs_update_delayed_inode(trans, root, path, node); // <- call here
1104 mutex_unlock(&node->mutex);
1105 return ret;
1106 }

--- __btrfs_commit_inode_delayed_items (fs/btrfs/delayed-inode.c:1127) ---

1108 static inline int
1109 __btrfs_commit_inode_delayed_items(struct btrfs_trans_handle *trans,
1110 struct btrfs_path *path,
1111 struct btrfs_delayed_node *node)
1112 {
1113 int ret;
1114
1115 ret = btrfs_insert_delayed_items(trans, path, node->root, node);
1116 if (ret)
1117 return ret;
1118
1119 ret = btrfs_delete_delayed_items(trans, path, node->root, node);
1120 if (ret)
1121 return ret;
1122
1123 ret = btrfs_record_root_in_trans(trans, node->root);
1124 if (ret)
1125 return ret;
1126
1127 return btrfs_update_delayed_inode(trans, node->root, path, node); // <- call here
1128 }

--- __btrfs_run_delayed_items (fs/btrfs/delayed-inode.c:1158) ---

1136 static int __btrfs_run_delayed_items(struct btrfs_trans_handle *trans, int nr)
1137 {
1138 struct btrfs_fs_info *fs_info = trans->fs_info;
...
1141 struct btrfs_path *path;
1142 struct btrfs_block_rsv *block_rsv;
...
1149 path = btrfs_alloc_path();
...
1153 block_rsv = trans->block_rsv;
1154 trans->block_rsv = &fs_info->delayed_block_rsv; // RSV switched to delayed_block_rsv
1155
1156 curr_node = btrfs_first_delayed_node(fs_info, &curr_delayed_node_tracker);
1157 while (curr_node && (!count || nr--)) {
1158 ret = __btrfs_commit_inode_delayed_items(trans, path, // <- call here
1159 curr_node);
1160 if (unlikely(ret)) {
1161 btrfs_abort_transaction(trans, ret);
1162 break;
1163 }
...

The WARN() fires inside the btrfs_abort_transaction macro when
btrfs_lookup_inode() returns -ENOSPC (-28) in
__btrfs_update_delayed_inode. The macro calls
btrfs_abort_should_print_stack(-28), which returns true because -ENOSPC
is not in the exception list (-EIO, -EROFS, -ENOMEM). This causes the
WARN() to fire and print the stack trace.

The root cause is a circular ENOSPC condition: the async data-space
reclaim path commits a transaction to free data space, but that
transaction commit needs metadata space for B-tree copy-on-write
operations (allocated from delayed_block_rsv). When both data and
metadata space are critically low, btrfs_search_slot fails with
-ENOSPC even for the deletion COW path.

The transaction abort is correct behavior for this failure. The issue
is that -ENOSPC is not an exceptional/unexpected error in this context
— it is a predictable outcome under severe space pressure — yet
btrfs_abort_should_print_stack() treats it as unexpected and fires
WARN().

Proposed fix: add -ENOSPC to the exception list in
btrfs_abort_should_print_stack() in fs/btrfs/transaction.h:

--- a/fs/btrfs/transaction.h
+++ b/fs/btrfs/transaction.h
@@ -236,6 +236,7 @@ static inline bool btrfs_abort_should_print_stack(int error)
switch (error) {
case -EIO:
case -EROFS:
+ case -ENOSPC:
case -ENOMEM:
return false;
}

This matches the intent of the list (errors that are expected/normal
filesystem conditions, not programming errors). The transaction is
still aborted correctly via __btrfs_abort_transaction(); only the
spurious stack-printing WARN() is suppressed.

A deeper fix would ensure delayed_block_rsv has sufficient reservation
to avoid the ENOSPC in the first place, but that is a harder problem
touching btrfs space-reservation accounting.

Full analysis at:
http://oops.fenrus.org/reports/lkml/69eb21b8.a00a0220.17a17.0056.GAE_google.com/report.md

Arjan van de Ven