[syzbot] [btrfs?] WARNING in __add_block_group_free_space

[syzbot] [btrfs?] WARNING in __add_block_group_free_space

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    06cf61899d64 Merge tag 'x86-urgent-2026-08-08' of git://gi..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15b27fb9580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=a59830cba91a1981
dashboard link: https://syzkaller.appspot.com/bug?extid=6931616d57696102d8aa
compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.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-06cf6189.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2c3ef8ca53e1/vmlinux-06cf6189.xz
kernel image: https://storage.googleapis.com/syzbot-assets/52ac12d71a9c/bzImage-06cf6189.xz

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

------------[ cut here ]------------
btrfs_abort_should_print_stack(__error)
WARNING: fs/btrfs/free-space-tree.c:1440 at __add_block_group_free_space+0x5a3/0x5b0 fs/btrfs/free-space-tree.c:1440, CPU#0: kworker/u4:3/41
Modules linked in:
CPU: 0 UID: 0 PID: 41 Comm: kworker/u4:3 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_metadata_space
RIP: 0010:__add_block_group_free_space+0x5a3/0x5b0 fs/btrfs/free-space-tree.c:1440
Code: 07 38 c1 0f 8c ce fc ff ff 4c 89 f7 e8 76 bc 00 fe e9 c1 fc ff ff e8 1c 87 91 fd eb 10 e8 15 87 91 fd eb 09 e8 0e 87 91 fd 90 <0f> 0b 90 44 89 e1 f7 d9 e9 51 fe ff ff 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffc900004374b8 EFLAGS: 00010293
RAX: ffffffff84358aa2 RBX: ffff888051eb8001 RCX: ffff88801ae58000
RDX: 0000000000000000 RSI: ffffffff8f1f5b20 RDI: 00000000ffffffe4
RBP: ffff888042b61490 R08: ffff88801ae58000 R09: 0000000000000003
R10: 00000000fffffffb R11: 0000000000000000 R12: 00000000ffffffe4
R13: ffff8880435d3790 R14: ffff888042b614f0 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88808c549000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055b6397df5f8 CR3: 00000000407ef000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 btrfs_add_block_group_free_space+0xd0/0x130 fs/btrfs/free-space-tree.c:1465
 btrfs_create_pending_block_groups+0xcc6/0x15e0 fs/btrfs/block-group.c:2952
 __btrfs_end_transaction+0x140/0x640 fs/btrfs/transaction.c:1092
 flush_space+0x3e9/0xde0 fs/btrfs/space-info.c:912
 do_async_reclaim_metadata_space+0x3e8/0x940 fs/btrfs/space-info.c:1211
 btrfs_async_reclaim_metadata_space+0x89/0xe0 fs/btrfs/space-info.c:1278
 process_one_work kernel/workqueue.c:3322 [inline]
 process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405
 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486
 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>


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

Re: [syzbot] [btrfs?] WARNING in __add_block_group_free_space

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:    36aad21d50d1 Merge tag 'ksmbd-for-7.4-rc1-part2' of git://..
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=113b8959580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=94cb1a71158c9027
dashboard link: https://syzkaller.appspot.com/bug?extid=6931616d57696102d8aa
compiler:       Debian clang version 22.1.8 (1~deb13u4), Debian LLD 22.1.8
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=147bccb1580000

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

------------[ cut here ]------------
btrfs_abort_should_print_stack(__error)
WARNING: fs/btrfs/free-space-tree.c:1446 at __add_block_group_free_space+0x5a3/0x5b0 fs/btrfs/free-space-tree.c:1446, CPU#0: kworker/u4:7/185
Modules linked in:
CPU: 0 UID: 0 PID: 185 Comm: kworker/u4:7 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:__add_block_group_free_space+0x5a3/0x5b0 fs/btrfs/free-space-tree.c:1446
Code: 07 38 c1 0f 8c ce fc ff ff 4c 89 f7 e8 66 3c f5 fd e9 c1 fc ff ff e8 cc 98 7c fd eb 10 e8 c5 98 7c fd eb 09 e8 be 98 7c fd 90 <0f> 0b 90 44 89 e1 f7 d9 e9 51 fe ff ff 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffc90001a7f578 EFLAGS: 00010293
RAX: ffffffff844c8872 RBX: ffff888013790001 RCX: ffff888034dc0000
RDX: 0000000000000000 RSI: ffffffff9081ef80 RDI: 00000000ffffffe4
RBP: ffff888037aea758 R08: ffff888034dc0000 R09: 0000000000000003
R10: 00000000fffffffb R11: 0000000000000000 R12: 00000000ffffffe4
R13: ffff88801377d000 R14: ffff888037aea7b8 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88808aa01000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4b3d8dd080 CR3: 0000000041dd5000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 btrfs_add_block_group_free_space+0xd0/0x130 fs/btrfs/free-space-tree.c:1471
 btrfs_create_pending_block_groups+0xcc6/0x15e0 fs/btrfs/block-group.c:2942
 __btrfs_end_transaction+0x140/0x640 fs/btrfs/transaction.c:1119
 flush_space+0x3e9/0xde0 fs/btrfs/space-info.c:912
 do_async_reclaim_data_space+0x137/0x550 fs/btrfs/space-info.c:1455
 btrfs_async_reclaim_data_space+0x41/0x90 fs/btrfs/space-info.c:1519
 process_one_work kernel/workqueue.c:3495 [inline]
 process_scheduled_works+0xc3d/0x1630 kernel/workqueue.c:3578
 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3659
 kthread+0x38b/0x480 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>


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

[PATCH] ocfs2: fix lockdep class of newly created directories

[Shuai Liu]

Directories and regular files use different lockdep classes for
i_rwsem (i_mutex_dir_key vs i_mutex_key) so that lockdep can verify
the documented locking order "parent[2] -> child -> normal" without
spurious class-level cycles: e.g. cross-directory rename takes
I_MUTEX_CHILD on the source directory followed by an unclassed
I_MUTEX_NORMAL on the target inode, while other paths take
I_MUTEX_NORMAL on a file before touching a child-class inode.

Since commit 14358e6ddaed ("lockdep: annotate dir vs file i_mutex"),
this split is applied in unlock_new_inode(), which relies on the
inode being created with I_NEW set.  ocfs2 creates inodes through
new_inode() (no I_NEW) and instantiates them with a plain
d_instantiate(), so lockdep_annotate_inode_mutex_key() never runs on
this path.  Every directory created after mount therefore keeps the
plain i_mutex_key class for its whole lifetime, breaking the
dir/file class separation that the VFS locking order relies on.

With such a directory the class-level chain

  i_mutex_key/I_MUTEX_NORMAL -> i_mutex_key/I_MUTEX_CHILD

recorded by the reflink path (ocfs2_vfs_reflink() locks the source
inode, then __ocfs2_reflink() takes I_MUTEX_CHILD on the orphan
inode) collides with the chain

  i_mutex_key/I_MUTEX_CHILD -> i_mutex_key

recorded by vfs_rename() when renaming a directory onto an existing
file, and lockdep reports a "possible deadlock in vfs_rename":

  syz-executor105/5623 is trying to acquire lock:
  ffff8880767009a0 (&sb->s_type->i_mutex_key#18){+.+.}-{4:4}, at: vfs_rename+0x6e3
  but task is already holding lock:
  ffff8880764ff9a0 (&sb->s_type->i_mutex_key#18/2){+.+.}-{4:4}, at: vfs_rename+0x64d

  Chain exists of:
    &sb->s_type->i_mutex_key#18 --> &oi->ip_alloc_sem --> &sb->s_type->i_mutex_key#18/2

Fix it by calling lockdep_annotate_inode_mutex_key() in
ocfs2_get_init_inode() right after the final mode is established,
before the inode can be found or locked by anyone else.  This is the
same treatment shmem got (commit b45d71fb89ab8adf, "mm: shmem.c:
Correctly annotate new inodes for lockdep"), following the hugetlbfs
pattern of annotating right after new inode creation.  Freshly
created ocfs2 directories are now properly separated from files in
lockdep and the rename vs reflink cycle disappears.

The C reproducer from syzbot (mount ocfs2 image, OCFS2_IOC_REFLINK,
mkdir two directories, rename a directory onto the reflinked file)
hits the lockdep warning on every run without the fix and runs
cleanly with it.

Reported-by: syzbot+c73ff6790f3d6c635abc@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c73ff6790f3d6c635abc
Fixes: 14358e6ddaed ("lockdep: annotate dir vs file i_mutex")
Signed-off-by: Shuai Liu <847807867@qq.com>
---
 fs/ocfs2/namei.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/fs/ocfs2/namei.c b/fs/ocfs2/namei.c
index d8759605786c4..f3ec348eb709d 100644
--- a/fs/ocfs2/namei.c
+++ b/fs/ocfs2/namei.c
@@ -203,6 +203,13 @@ static struct inode *ocfs2_get_init_inode(struct inode *dir, umode_t mode)
 		set_nlink(inode, 2);
 	mode = mode_strip_sgid(&nop_mnt_idmap, dir, mode);
 	inode_init_owner(&nop_mnt_idmap, inode, dir, mode);
+	/*
+	 * This inode never goes through unlock_new_inode() (there is no
+	 * I_NEW state on this path), so the directory vs file lockdep
+	 * class split for i_rwsem has to be done here, before the inode
+	 * becomes visible to anybody else.
+	 */
+	lockdep_annotate_inode_mutex_key(inode);
 	status = dquot_initialize(inode);
 	if (status) {
 		iput(inode);
-- 
2.43.0

Re: [PATCH] ocfs2: fix lockdep class of newly created directories

[Joseph Qi]

On 11/10/26 9:45 AM, Shuai Liu wrote:
> Directories and regular files use different lockdep classes for
> i_rwsem (i_mutex_dir_key vs i_mutex_key) so that lockdep can verify
> the documented locking order "parent[2] -> child -> normal" without
> spurious class-level cycles: e.g. cross-directory rename takes
> I_MUTEX_CHILD on the source directory followed by an unclassed
> I_MUTEX_NORMAL on the target inode, while other paths take
> I_MUTEX_NORMAL on a file before touching a child-class inode.
> 
> Since commit 14358e6ddaed ("lockdep: annotate dir vs file i_mutex"),
> this split is applied in unlock_new_inode(), which relies on the
> inode being created with I_NEW set.  ocfs2 creates inodes through
> new_inode() (no I_NEW) and instantiates them with a plain
> d_instantiate(), so lockdep_annotate_inode_mutex_key() never runs on
> this path.  Every directory created after mount therefore keeps the
> plain i_mutex_key class for its whole lifetime, breaking the
> dir/file class separation that the VFS locking order relies on.
> 
> With such a directory the class-level chain
> 
>   i_mutex_key/I_MUTEX_NORMAL -> i_mutex_key/I_MUTEX_CHILD
> 
> recorded by the reflink path (ocfs2_vfs_reflink() locks the source
> inode, then __ocfs2_reflink() takes I_MUTEX_CHILD on the orphan
> inode) collides with the chain
> 
>   i_mutex_key/I_MUTEX_CHILD -> i_mutex_key
> 
> recorded by vfs_rename() when renaming a directory onto an existing
> file, and lockdep reports a "possible deadlock in vfs_rename":
> 
>   syz-executor105/5623 is trying to acquire lock:
>   ffff8880767009a0 (&sb->s_type->i_mutex_key#18){+.+.}-{4:4}, at: vfs_rename+0x6e3
>   but task is already holding lock:
>   ffff8880764ff9a0 (&sb->s_type->i_mutex_key#18/2){+.+.}-{4:4}, at: vfs_rename+0x64d
> 
>   Chain exists of:
>     &sb->s_type->i_mutex_key#18 --> &oi->ip_alloc_sem --> &sb->s_type->i_mutex_key#18/2
> 
> Fix it by calling lockdep_annotate_inode_mutex_key() in
> ocfs2_get_init_inode() right after the final mode is established,
> before the inode can be found or locked by anyone else.  This is the
> same treatment shmem got (commit b45d71fb89ab8adf, "mm: shmem.c:
> Correctly annotate new inodes for lockdep"), following the hugetlbfs
> pattern of annotating right after new inode creation.  Freshly
> created ocfs2 directories are now properly separated from files in
> lockdep and the rename vs reflink cycle disappears.
> 
> The C reproducer from syzbot (mount ocfs2 image, OCFS2_IOC_REFLINK,
> mkdir two directories, rename a directory onto the reflinked file)
> hits the lockdep warning on every run without the fix and runs
> cleanly with it.
> 
> Reported-by: syzbot+c73ff6790f3d6c635abc@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=c73ff6790f3d6c635abc
> Fixes: 14358e6ddaed ("lockdep: annotate dir vs file i_mutex")
> Signed-off-by: Shuai Liu <847807867@qq.com>

Looks fine.
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
> ---
>  fs/ocfs2/namei.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/fs/ocfs2/namei.c b/fs/ocfs2/namei.c
> index d8759605786c4..f3ec348eb709d 100644
> --- a/fs/ocfs2/namei.c
> +++ b/fs/ocfs2/namei.c
> @@ -203,6 +203,13 @@ static struct inode *ocfs2_get_init_inode(struct inode *dir, umode_t mode)
>  		set_nlink(inode, 2);
>  	mode = mode_strip_sgid(&nop_mnt_idmap, dir, mode);
>  	inode_init_owner(&nop_mnt_idmap, inode, dir, mode);
> +	/*
> +	 * This inode never goes through unlock_new_inode() (there is no
> +	 * I_NEW state on this path), so the directory vs file lockdep
> +	 * class split for i_rwsem has to be done here, before the inode
> +	 * becomes visible to anybody else.
> +	 */
> +	lockdep_annotate_inode_mutex_key(inode);
>  	status = dquot_initialize(inode);
>  	if (status) {
>  		iput(inode);