[v6.1] possible deadlock in ext4_evict_inode (4)

0 views
Skip to first unread message

syzbot

unread,
Nov 22, 2025, 1:47:26 PM (yesterday) Nov 22
to syzkaller...@googlegroups.com
Hello,

syzbot found the following issue on:

HEAD commit: f6e38ae624cf Linux 6.1.158
git tree: linux-6.1.y
console output: https://syzkaller.appspot.com/x/log.txt?x=1681b658580000
kernel config: https://syzkaller.appspot.com/x/.config?x=68aa5a3af1cb953a
dashboard link: https://syzkaller.appspot.com/bug?extid=dab0c857fae30b036d17
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
userspace arch: arm64

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

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/c1bd671a9def/disk-f6e38ae6.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/fa0af998ea40/vmlinux-f6e38ae6.xz
kernel image: https://storage.googleapis.com/syzbot-assets/e5512d873524/Image-f6e38ae6.gz.xz

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

loop5: detected capacity change from 0 to 128
EXT4-fs (loop5): mounted filesystem without journal. Quota mode: none.
======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
syz.5.413/6538 is trying to acquire lock:
ffff0000cf572650 (sb_internal){.+.+}-{0:0}, at: __sb_start_write include/linux/fs.h:1891 [inline]
ffff0000cf572650 (sb_internal){.+.+}-{0:0}, at: sb_start_intwrite include/linux/fs.h:2013 [inline]
ffff0000cf572650 (sb_internal){.+.+}-{0:0}, at: ext4_evict_inode+0x3dc/0x1270 fs/ext4/inode.c:240

but task is already holding lock:
ffff0000cf576b98 (&sbi->s_writepages_rwsem){++++}-{0:0}, at: ext4_ext_migrate+0x204/0xbfc fs/ext4/migrate.c:437

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&sbi->s_writepages_rwsem){++++}-{0:0}:
percpu_down_read+0x70/0x2a8 include/linux/percpu-rwsem.h:51
ext4_writepages+0x188/0x284c fs/ext4/inode.c:2715
do_writepages+0x2c0/0x4fc mm/page-writeback.c:2491
__writeback_single_inode+0x164/0x157c fs/fs-writeback.c:1622
writeback_single_inode+0x1c0/0x720 fs/fs-writeback.c:1743
write_inode_now+0x144/0x1b0 fs/fs-writeback.c:2780
iput_final fs/inode.c:1821 [inline]
iput+0x5cc/0x7f4 fs/inode.c:1860
ext4_xattr_block_set+0x17a4/0x2810 fs/ext4/xattr.c:2158
ext4_xattr_move_to_block fs/ext4/xattr.c:2626 [inline]
ext4_xattr_make_inode_space fs/ext4/xattr.c:2701 [inline]
ext4_expand_extra_isize_ea+0xcb8/0x15cc fs/ext4/xattr.c:2793
__ext4_expand_extra_isize+0x298/0x358 fs/ext4/inode.c:5980
ext4_try_to_expand_extra_isize fs/ext4/inode.c:6023 [inline]
__ext4_mark_inode_dirty+0x3e4/0x790 fs/ext4/inode.c:6101
ext4_evict_inode+0xb58/0x1270 fs/ext4/inode.c:279
evict+0x3c8/0x810 fs/inode.c:705
iput_final fs/inode.c:1834 [inline]
iput+0x764/0x7f4 fs/inode.c:1860
ext4_process_orphan+0x240/0x2b4 fs/ext4/orphan.c:356
ext4_orphan_cleanup+0x908/0x104c fs/ext4/orphan.c:470
__ext4_fill_super fs/ext4/super.c:5530 [inline]
ext4_fill_super+0x6440/0x68a8 fs/ext4/super.c:5661
get_tree_bdev+0x358/0x544 fs/super.c:1366
ext4_get_tree+0x28/0x38 fs/ext4/super.c:5691
vfs_get_tree+0x90/0x274 fs/super.c:1573
do_new_mount+0x228/0x810 fs/namespace.c:3078
path_mount+0x5b4/0xe78 fs/namespace.c:3408
do_mount fs/namespace.c:3421 [inline]
__do_sys_mount fs/namespace.c:3629 [inline]
__se_sys_mount fs/namespace.c:3606 [inline]
__arm64_sys_mount+0x49c/0x584 fs/namespace.c:3606
__invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
invoke_syscall+0x98/0x2bc arch/arm64/kernel/syscall.c:52
el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:140
do_el0_svc+0x58/0x13c arch/arm64/kernel/syscall.c:204
el0_svc+0x58/0x138 arch/arm64/kernel/entry-common.c:637
el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655
el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:585

-> #0 (sb_internal){.+.+}-{0:0}:
check_prev_add kernel/locking/lockdep.c:3090 [inline]
check_prevs_add kernel/locking/lockdep.c:3209 [inline]
validate_chain kernel/locking/lockdep.c:3825 [inline]
__lock_acquire+0x293c/0x6544 kernel/locking/lockdep.c:5049
lock_acquire+0x20c/0x644 kernel/locking/lockdep.c:5662
percpu_down_read+0x70/0x2a8 include/linux/percpu-rwsem.h:51
__sb_start_write include/linux/fs.h:1891 [inline]
sb_start_intwrite include/linux/fs.h:2013 [inline]
ext4_evict_inode+0x3dc/0x1270 fs/ext4/inode.c:240
evict+0x3c8/0x810 fs/inode.c:705
iput_final fs/inode.c:1834 [inline]
iput+0x764/0x7f4 fs/inode.c:1860
ext4_ext_migrate+0x9dc/0xbfc fs/ext4/migrate.c:587
__ext4_ioctl fs/ext4/ioctl.c:1396 [inline]
ext4_ioctl+0x1a38/0x4198 fs/ext4/ioctl.c:1614
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl fs/ioctl.c:856 [inline]
__arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:856
__invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
invoke_syscall+0x98/0x2bc arch/arm64/kernel/syscall.c:52
el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:140
do_el0_svc+0x58/0x13c arch/arm64/kernel/syscall.c:204
el0_svc+0x58/0x138 arch/arm64/kernel/entry-common.c:637
el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655
el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:585

other info that might help us debug this:

Possible unsafe locking scenario:

CPU0 CPU1
---- ----
lock(&sbi->s_writepages_rwsem);
lock(sb_internal);
lock(&sbi->s_writepages_rwsem);
lock(sb_internal);

*** DEADLOCK ***

3 locks held by syz.5.413/6538:
#0: ffff0000cf572460 (sb_writers#3){.+.+}-{0:0}, at: mnt_want_write_file+0x64/0x1e8 fs/namespace.c:446
#1: ffff0000e0393628 (&sb->s_type->i_mutex_key#9){++++}-{3:3}, at: inode_lock include/linux/fs.h:758 [inline]
#1: ffff0000e0393628 (&sb->s_type->i_mutex_key#9){++++}-{3:3}, at: __ext4_ioctl fs/ext4/ioctl.c:1395 [inline]
#1: ffff0000e0393628 (&sb->s_type->i_mutex_key#9){++++}-{3:3}, at: ext4_ioctl+0x1a30/0x4198 fs/ext4/ioctl.c:1614
#2: ffff0000cf576b98 (&sbi->s_writepages_rwsem){++++}-{0:0}, at: ext4_ext_migrate+0x204/0xbfc fs/ext4/migrate.c:437

stack backtrace:
CPU: 0 PID: 6538 Comm: syz.5.413 Not tainted syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/03/2025
Call trace:
dump_backtrace+0x1c8/0x1f4 arch/arm64/kernel/stacktrace.c:158
show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:165
__dump_stack+0x30/0x40 lib/dump_stack.c:88
dump_stack_lvl+0xf8/0x160 lib/dump_stack.c:106
dump_stack+0x1c/0x5c lib/dump_stack.c:113
print_circular_bug+0x148/0x1b0 kernel/locking/lockdep.c:2048
check_noncircular+0x240/0x2d4 kernel/locking/lockdep.c:2170
check_prev_add kernel/locking/lockdep.c:3090 [inline]
check_prevs_add kernel/locking/lockdep.c:3209 [inline]
validate_chain kernel/locking/lockdep.c:3825 [inline]
__lock_acquire+0x293c/0x6544 kernel/locking/lockdep.c:5049
lock_acquire+0x20c/0x644 kernel/locking/lockdep.c:5662
percpu_down_read+0x70/0x2a8 include/linux/percpu-rwsem.h:51
__sb_start_write include/linux/fs.h:1891 [inline]
sb_start_intwrite include/linux/fs.h:2013 [inline]
ext4_evict_inode+0x3dc/0x1270 fs/ext4/inode.c:240
evict+0x3c8/0x810 fs/inode.c:705
iput_final fs/inode.c:1834 [inline]
iput+0x764/0x7f4 fs/inode.c:1860
ext4_ext_migrate+0x9dc/0xbfc fs/ext4/migrate.c:587
__ext4_ioctl fs/ext4/ioctl.c:1396 [inline]
ext4_ioctl+0x1a38/0x4198 fs/ext4/ioctl.c:1614
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl fs/ioctl.c:856 [inline]
__arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:856
__invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
invoke_syscall+0x98/0x2bc arch/arm64/kernel/syscall.c:52
el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:140
do_el0_svc+0x58/0x13c arch/arm64/kernel/syscall.c:204
el0_svc+0x58/0x138 arch/arm64/kernel/entry-common.c:637
el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655
el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:585


---
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
Reply all
Reply to author
Forward
0 new messages