[v6.6] possible deadlock in __ocfs2_flush_truncate_log

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 6282921b6825 Linux 6.6.94
git tree: linux-6.6.y
console output: https://syzkaller.appspot.com/x/log.txt?x=17263b70580000
kernel config: https://syzkaller.appspot.com/x/.config?x=96da6b2210cda427
dashboard link: https://syzkaller.appspot.com/bug?extid=579f76264f7c6b368047
compiler: Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6

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

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/a3bf0d8e22b2/disk-6282921b.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/d1d442f782d0/vmlinux-6282921b.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a8378f4b7e1b/bzImage-6282921b.xz

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

======================================================
WARNING: possible circular locking dependency detected
6.6.94-syzkaller #0 Not tainted
------------------------------------------------------
syz-executor/11486 is trying to acquire lock:
ffff88805aa86d98 (&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#6){+.+.}-{3:3}, at: inode_lock include/linux/fs.h:804 [inline]
ffff88805aa86d98 (&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#6){+.+.}-{3:3}, at: __ocfs2_flush_truncate_log+0x351/0x10b0 fs/ocfs2/alloc.c:6047

but task is already holding lock:
ffff88805ab1d118 (&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#5){+.+.}-{3:3}, at: inode_lock include/linux/fs.h:804 [inline]
ffff88805ab1d118 (&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#5){+.+.}-{3:3}, at: ocfs2_flush_truncate_log+0x47/0x60 fs/ocfs2/alloc.c:6076

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#5){+.+.}-{3:3}:
down_write+0x97/0x1f0 kernel/locking/rwsem.c:1573
inode_lock include/linux/fs.h:804 [inline]
ocfs2_move_extent fs/ocfs2/move_extents.c:640 [inline]
__ocfs2_move_extents_range+0x1a65/0x3360 fs/ocfs2/move_extents.c:860
ocfs2_move_extents+0x379/0x940 fs/ocfs2/move_extents.c:927
ocfs2_ioctl_move_extents+0x4e1/0x6c0 fs/ocfs2/move_extents.c:1053
ocfs2_ioctl+0x195/0x750 fs/ocfs2/ioctl.c:945
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:871 [inline]
__se_sys_ioctl+0xfd/0x170 fs/ioctl.c:857
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x55/0xb0 arch/x86/entry/common.c:81
entry_SYSCALL_64_after_hwframe+0x68/0xd2

-> #0 (&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#6){+.+.}-{3:3}:
check_prev_add kernel/locking/lockdep.c:3134 [inline]
check_prevs_add kernel/locking/lockdep.c:3253 [inline]
validate_chain kernel/locking/lockdep.c:3869 [inline]
__lock_acquire+0x2ddb/0x7c80 kernel/locking/lockdep.c:5137
lock_acquire+0x197/0x410 kernel/locking/lockdep.c:5754
down_write+0x97/0x1f0 kernel/locking/rwsem.c:1573
inode_lock include/linux/fs.h:804 [inline]
__ocfs2_flush_truncate_log+0x351/0x10b0 fs/ocfs2/alloc.c:6047
ocfs2_flush_truncate_log+0x4f/0x60 fs/ocfs2/alloc.c:6077
ocfs2_sync_fs+0x117/0x310 fs/ocfs2/super.c:402
sync_filesystem+0x1c2/0x220 fs/sync.c:66
generic_shutdown_super+0x6f/0x2b0 fs/super.c:666
kill_block_super+0x44/0x90 fs/super.c:1660
deactivate_locked_super+0x97/0x100 fs/super.c:481
cleanup_mnt+0x429/0x4c0 fs/namespace.c:1250
task_work_run+0x1ce/0x250 kernel/task_work.c:239
resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
exit_to_user_mode_loop+0xe6/0x110 kernel/entry/common.c:177
exit_to_user_mode_prepare+0xb1/0x140 kernel/entry/common.c:210
__syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
syscall_exit_to_user_mode+0x1a/0x50 kernel/entry/common.c:302
do_syscall_64+0x61/0xb0 arch/x86/entry/common.c:87
entry_SYSCALL_64_after_hwframe+0x68/0xd2

other info that might help us debug this:

Possible unsafe locking scenario:

CPU0 CPU1
---- ----
lock(&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#5);
lock(&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#6);
lock(&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#5);
lock(&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#6);

*** DEADLOCK ***

2 locks held by syz-executor/11486:
#0: ffff8880784160e0 (&type->s_umount_key#75){++++}-{3:3}, at: __super_lock fs/super.c:56 [inline]
#0: ffff8880784160e0 (&type->s_umount_key#75){++++}-{3:3}, at: __super_lock_excl fs/super.c:71 [inline]
#0: ffff8880784160e0 (&type->s_umount_key#75){++++}-{3:3}, at: deactivate_super+0xa4/0xe0 fs/super.c:513
#1: ffff88805ab1d118 (&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#5){+.+.}-{3:3}, at: inode_lock include/linux/fs.h:804 [inline]
#1: ffff88805ab1d118 (&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#5){+.+.}-{3:3}, at: ocfs2_flush_truncate_log+0x47/0x60 fs/ocfs2/alloc.c:6076

stack backtrace:
CPU: 0 PID: 11486 Comm: syz-executor Not tainted 6.6.94-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
<TASK>
dump_stack_lvl+0x16c/0x230 lib/dump_stack.c:106
check_noncircular+0x2bd/0x3c0 kernel/locking/lockdep.c:2187
check_prev_add kernel/locking/lockdep.c:3134 [inline]
check_prevs_add kernel/locking/lockdep.c:3253 [inline]
validate_chain kernel/locking/lockdep.c:3869 [inline]
__lock_acquire+0x2ddb/0x7c80 kernel/locking/lockdep.c:5137
lock_acquire+0x197/0x410 kernel/locking/lockdep.c:5754
down_write+0x97/0x1f0 kernel/locking/rwsem.c:1573
inode_lock include/linux/fs.h:804 [inline]
__ocfs2_flush_truncate_log+0x351/0x10b0 fs/ocfs2/alloc.c:6047
ocfs2_flush_truncate_log+0x4f/0x60 fs/ocfs2/alloc.c:6077
ocfs2_sync_fs+0x117/0x310 fs/ocfs2/super.c:402
sync_filesystem+0x1c2/0x220 fs/sync.c:66
generic_shutdown_super+0x6f/0x2b0 fs/super.c:666
kill_block_super+0x44/0x90 fs/super.c:1660
deactivate_locked_super+0x97/0x100 fs/super.c:481
cleanup_mnt+0x429/0x4c0 fs/namespace.c:1250
task_work_run+0x1ce/0x250 kernel/task_work.c:239
resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
exit_to_user_mode_loop+0xe6/0x110 kernel/entry/common.c:177
exit_to_user_mode_prepare+0xb1/0x140 kernel/entry/common.c:210
__syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
syscall_exit_to_user_mode+0x1a/0x50 kernel/entry/common.c:302
do_syscall_64+0x61/0xb0 arch/x86/entry/common.c:87
entry_SYSCALL_64_after_hwframe+0x68/0xd2
RIP: 0033:0x7f7e4e18fc57
Code: a8 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 01 c3 48 c7 c2 a8 ff ff ff f7 d8 64 89 02 b8
RSP: 002b:00007ffd8e869c68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
RAX: 0000000000000000 RBX: 00007f7e4e210925 RCX: 00007f7e4e18fc57
RDX: 0000000000000000 RSI: 0000000000000009 RDI: 00007ffd8e869d20
RBP: 00007ffd8e869d20 R08: 0000000000000000 R09: 0000000000000000
R10: 00000000ffffffff R11: 0000000000000246 R12: 00007ffd8e86adb0
R13: 00007f7e4e210925 R14: 00000000001310c4 R15: 00007ffd8e86adf0
</TASK>
ocfs2: Unmounting device (7,5) on (node local)


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

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit: 3f5b4c104b7d Linux 6.6.95
git tree: linux-6.6.y
console output: https://syzkaller.appspot.com/x/log.txt?x=17e423d4580000
kernel config: https://syzkaller.appspot.com/x/.config?x=b80883c3ded77c16

dashboard link: https://syzkaller.appspot.com/bug?extid=579f76264f7c6b368047
compiler: Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6

syz repro: https://syzkaller.appspot.com/x/repro.syz?x=131d4982580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1478088c580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/0efd4e01816e/disk-3f5b4c10.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/f7c9d20858cc/vmlinux-3f5b4c10.xz
kernel image: https://storage.googleapis.com/syzbot-assets/18f8dc74ef68/bzImage-3f5b4c10.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/1623764fa6e1/mount_0.gz
fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=151d4982580000)

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

======================================================
WARNING: possible circular locking dependency detected

6.6.95-syzkaller #0 Not tainted
------------------------------------------------------
syz-executor/5883 is trying to acquire lock:
ffff888061c05118 (&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#5){+.+.}-{3:3}, at: inode_lock include/linux/fs.h:804 [inline]
ffff888061c05118 (&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#5){+.+.}-{3:3}, at: __ocfs2_flush_truncate_log+0x351/0x10b0 fs/ocfs2/alloc.c:6047

but task is already holding lock:

ffff888061d83498 (&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#6){+.+.}-{3:3}, at: inode_lock include/linux/fs.h:804 [inline]
ffff888061d83498 (&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#6){+.+.}-{3:3}, at: ocfs2_flush_truncate_log+0x47/0x60 fs/ocfs2/alloc.c:6076

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#6){+.+.}-{3:3}:

down_write+0x97/0x1f0 kernel/locking/rwsem.c:1573
inode_lock include/linux/fs.h:804 [inline]
ocfs2_move_extent fs/ocfs2/move_extents.c:640 [inline]
__ocfs2_move_extents_range+0x1a65/0x3360 fs/ocfs2/move_extents.c:860
ocfs2_move_extents+0x379/0x940 fs/ocfs2/move_extents.c:927
ocfs2_ioctl_move_extents+0x4e1/0x6c0 fs/ocfs2/move_extents.c:1053
ocfs2_ioctl+0x195/0x750 fs/ocfs2/ioctl.c:945
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:871 [inline]
__se_sys_ioctl+0xfd/0x170 fs/ioctl.c:857
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x55/0xb0 arch/x86/entry/common.c:81
entry_SYSCALL_64_after_hwframe+0x68/0xd2

-> #0 (&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#5){+.+.}-{3:3}:

lock(&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#6);
lock(&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#5);
lock(&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#6);

lock(&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#5);

*** DEADLOCK ***

2 locks held by syz-executor/5883:
#0: ffff88807cb580e0 (&type->s_umount_key#56){+.+.}-{3:3}, at: __super_lock fs/super.c:56 [inline]
#0: ffff88807cb580e0 (&type->s_umount_key#56){+.+.}-{3:3}, at: __super_lock_excl fs/super.c:71 [inline]
#0: ffff88807cb580e0 (&type->s_umount_key#56){+.+.}-{3:3}, at: deactivate_super+0xa4/0xe0 fs/super.c:513
#1: ffff888061d83498 (&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#6){+.+.}-{3:3}, at: inode_lock include/linux/fs.h:804 [inline]
#1: ffff888061d83498 (&ocfs2_sysfile_lock_key[args->fi_sysfile_type]#6){+.+.}-{3:3}, at: ocfs2_flush_truncate_log+0x47/0x60 fs/ocfs2/alloc.c:6076

stack backtrace:
CPU: 1 PID: 5883 Comm: syz-executor Not tainted 6.6.95-syzkaller #0

RIP: 0033:0x7f222e38fc57

Code: a8 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 01 c3 48 c7 c2 a8 ff ff ff f7 d8 64 89 02 b8

RSP: 002b:00007ffcdee30598 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
RAX: 0000000000000000 RBX: 00007f222e410925 RCX: 00007f222e38fc57
RDX: 0000000000000000 RSI: 0000000000000009 RDI: 00007ffcdee30650
RBP: 00007ffcdee30650 R08: 0000000000000000 R09: 0000000000000000
R10: 00000000ffffffff R11: 0000000000000246 R12: 00007ffcdee316e0
R13: 00007f222e410925 R14: 00000000000198a1 R15: 00007ffcdee31720
</TASK>
ocfs2: Unmounting device (7,0) on (node local)


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