From: syzbot <syzbot+bb2455d02bda0b5701e3@syzkaller.appspotmail.com>
To: adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
tytso@mit.edu
Subject: Re: [syzbot] [ext4?] possible deadlock in ext4_destroy_inline_data (2)
Date: Sun, 30 Nov 2025 22:21:20 -0800 [thread overview]
Message-ID: <692d33e0.a70a0220.d98e3.017d.GAE@google.com> (raw)
In-Reply-To: <690bcad7.050a0220.baf87.0076.GAE@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: 7d31f578f323 Add linux-next specific files for 20251128
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1209f912580000
kernel config: https://syzkaller.appspot.com/x/.config?x=6336d8e94a7c517d
dashboard link: https://syzkaller.appspot.com/bug?extid=bb2455d02bda0b5701e3
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1442c192580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=108802b4580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/6b49d8ad90de/disk-7d31f578.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/dbe2d4988ca7/vmlinux-7d31f578.xz
kernel image: https://storage.googleapis.com/syzbot-assets/fc0448ab2411/bzImage-7d31f578.xz
mounted in repro #1: https://storage.googleapis.com/syzbot-assets/c224e4ae2f71/mount_0.gz
fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=16b5c512580000)
mounted in repro #2: https://storage.googleapis.com/syzbot-assets/6a86b64b703d/mount_1.gz
fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=170802b4580000)
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+bb2455d02bda0b5701e3@syzkaller.appspotmail.com
EXT4-fs: Ignoring removed bh option
EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.
======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
syz.0.28/6033 is trying to acquire lock:
ffff88805e5deaa8 (&ei->xattr_sem){++++}-{4:4}, at: ext4_write_lock_xattr fs/ext4/xattr.h:157 [inline]
ffff88805e5deaa8 (&ei->xattr_sem){++++}-{4:4}, at: ext4_destroy_inline_data+0x28/0xe0 fs/ext4/inline.c:1797
but task is already holding lock:
ffff8880347c0b98 (&sbi->s_writepages_rwsem){++++}-{0:0}, at: percpu_down_read include/linux/percpu-rwsem.h:77 [inline]
ffff8880347c0b98 (&sbi->s_writepages_rwsem){++++}-{0:0}, at: ext4_writepages_down_read fs/ext4/ext4.h:1820 [inline]
ffff8880347c0b98 (&sbi->s_writepages_rwsem){++++}-{0:0}, at: ext4_writepages+0x1ca/0x350 fs/ext4/inode.c:3025
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_internal+0x48/0x1c0 include/linux/percpu-rwsem.h:53
percpu_down_read include/linux/percpu-rwsem.h:77 [inline]
ext4_writepages_down_read fs/ext4/ext4.h:1820 [inline]
ext4_writepages+0x1ca/0x350 fs/ext4/inode.c:3025
do_writepages+0x32e/0x550 mm/page-writeback.c:2598
__writeback_single_inode+0x133/0x1240 fs/fs-writeback.c:1737
writeback_single_inode+0x493/0xc70 fs/fs-writeback.c:1858
write_inode_now+0x160/0x1d0 fs/fs-writeback.c:2924
iput_final fs/inode.c:1941 [inline]
iput+0xa77/0x1030 fs/inode.c:2003
ext4_xattr_block_set+0x1fce/0x2ac0 fs/ext4/xattr.c:2203
ext4_xattr_move_to_block fs/ext4/xattr.c:2668 [inline]
ext4_xattr_make_inode_space fs/ext4/xattr.c:2743 [inline]
ext4_expand_extra_isize_ea+0x12da/0x1ea0 fs/ext4/xattr.c:2831
__ext4_expand_extra_isize+0x30d/0x400 fs/ext4/inode.c:6349
ext4_try_to_expand_extra_isize fs/ext4/inode.c:6392 [inline]
__ext4_mark_inode_dirty+0x45c/0x6e0 fs/ext4/inode.c:6470
ext4_evict_inode+0x79c/0xe60 fs/ext4/inode.c:253
evict+0x5f4/0xae0 fs/inode.c:837
ext4_orphan_cleanup+0xc20/0x1460 fs/ext4/orphan.c:472
__ext4_fill_super fs/ext4/super.c:5658 [inline]
ext4_fill_super+0x58a1/0x6160 fs/ext4/super.c:5777
get_tree_bdev_flags+0x40e/0x4d0 fs/super.c:1691
vfs_get_tree+0x92/0x2a0 fs/super.c:1751
fc_mount fs/namespace.c:1209 [inline]
do_new_mount_fc fs/namespace.c:3646 [inline]
do_new_mount+0x302/0xa10 fs/namespace.c:3722
do_mount fs/namespace.c:4045 [inline]
__do_sys_mount fs/namespace.c:4234 [inline]
__se_sys_mount+0x313/0x410 fs/namespace.c:4211
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (&ei->xattr_sem){++++}-{4:4}:
check_prev_add kernel/locking/lockdep.c:3165 [inline]
check_prevs_add kernel/locking/lockdep.c:3284 [inline]
validate_chain kernel/locking/lockdep.c:3908 [inline]
__lock_acquire+0x15a6/0x2cf0 kernel/locking/lockdep.c:5237
lock_acquire+0x117/0x340 kernel/locking/lockdep.c:5868
down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590
ext4_write_lock_xattr fs/ext4/xattr.h:157 [inline]
ext4_destroy_inline_data+0x28/0xe0 fs/ext4/inline.c:1797
ext4_do_writepages+0x4e6/0x4500 fs/ext4/inode.c:2811
ext4_writepages+0x203/0x350 fs/ext4/inode.c:3026
do_writepages+0x32e/0x550 mm/page-writeback.c:2598
filemap_writeback mm/filemap.c:387 [inline]
filemap_fdatawrite_range mm/filemap.c:412 [inline]
file_write_and_wait_range+0x23e/0x340 mm/filemap.c:786
generic_buffers_fsync_noflush+0x70/0x1d0 fs/buffer.c:609
ext4_fsync_nojournal fs/ext4/fsync.c:88 [inline]
ext4_sync_file+0x322/0xae0 fs/ext4/fsync.c:147
generic_write_sync include/linux/fs.h:2616 [inline]
ext4_buffered_write_iter+0x2ca/0x3a0 fs/ext4/file.c:305
ext4_file_write_iter+0x292/0x1bc0 fs/ext4/file.c:-1
new_sync_write fs/read_write.c:593 [inline]
vfs_write+0x5c9/0xb30 fs/read_write.c:686
ksys_pwrite64 fs/read_write.c:793 [inline]
__do_sys_pwrite64 fs/read_write.c:801 [inline]
__se_sys_pwrite64 fs/read_write.c:798 [inline]
__x64_sys_pwrite64+0x193/0x220 fs/read_write.c:798
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
rlock(&sbi->s_writepages_rwsem);
lock(&ei->xattr_sem);
lock(&sbi->s_writepages_rwsem);
lock(&ei->xattr_sem);
*** DEADLOCK ***
2 locks held by syz.0.28/6033:
#0: ffff8880347c2420 (sb_writers#4){.+.+}-{0:0}, at: file_start_write include/linux/fs.h:2681 [inline]
#0: ffff8880347c2420 (sb_writers#4){.+.+}-{0:0}, at: vfs_write+0x211/0xb30 fs/read_write.c:682
#1: ffff8880347c0b98 (&sbi->s_writepages_rwsem){++++}-{0:0}, at: percpu_down_read include/linux/percpu-rwsem.h:77 [inline]
#1: ffff8880347c0b98 (&sbi->s_writepages_rwsem){++++}-{0:0}, at: ext4_writepages_down_read fs/ext4/ext4.h:1820 [inline]
#1: ffff8880347c0b98 (&sbi->s_writepages_rwsem){++++}-{0:0}, at: ext4_writepages+0x1ca/0x350 fs/ext4/inode.c:3025
stack backtrace:
CPU: 1 UID: 0 PID: 6033 Comm: syz.0.28 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
print_circular_bug+0x2e2/0x300 kernel/locking/lockdep.c:2043
check_noncircular+0x12e/0x150 kernel/locking/lockdep.c:2175
check_prev_add kernel/locking/lockdep.c:3165 [inline]
check_prevs_add kernel/locking/lockdep.c:3284 [inline]
validate_chain kernel/locking/lockdep.c:3908 [inline]
__lock_acquire+0x15a6/0x2cf0 kernel/locking/lockdep.c:5237
lock_acquire+0x117/0x340 kernel/locking/lockdep.c:5868
down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590
ext4_write_lock_xattr fs/ext4/xattr.h:157 [inline]
ext4_destroy_inline_data+0x28/0xe0 fs/ext4/inline.c:1797
ext4_do_writepages+0x4e6/0x4500 fs/ext4/inode.c:2811
ext4_writepages+0x203/0x350 fs/ext4/inode.c:3026
do_writepages+0x32e/0x550 mm/page-writeback.c:2598
filemap_writeback mm/filemap.c:387 [inline]
filemap_fdatawrite_range mm/filemap.c:412 [inline]
file_write_and_wait_range+0x23e/0x340 mm/filemap.c:786
generic_buffers_fsync_noflush+0x70/0x1d0 fs/buffer.c:609
ext4_fsync_nojournal fs/ext4/fsync.c:88 [inline]
ext4_sync_file+0x322/0xae0 fs/ext4/fsync.c:147
generic_write_sync include/linux/fs.h:2616 [inline]
ext4_buffered_write_iter+0x2ca/0x3a0 fs/ext4/file.c:305
ext4_file_write_iter+0x292/0x1bc0 fs/ext4/file.c:-1
new_sync_write fs/read_write.c:593 [inline]
vfs_write+0x5c9/0xb30 fs/read_write.c:686
ksys_pwrite64 fs/read_write.c:793 [inline]
__do_sys_pwrite64 fs/read_write.c:801 [inline]
__se_sys_pwrite64 fs/read_write.c:798 [inline]
__x64_sys_pwrite64+0x193/0x220 fs/read_write.c:798
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f2eec38f749
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff228a92f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000012
RAX: ffffffffffffffda RBX: 00007f2eec5e5fa0 RCX: 00007f2eec38f749
RDX: 000000000000fdef RSI: 0000200000000140 RDI: 0000000000000004
RBP: 00007f2eec413f91 R08: 0000000000000000 R09: 0000000000000000
R10: 000000000000fecc R11: 0000000000000246 R12: 0000000000000000
R13: 00007f2eec5e5fa0 R14: 00007f2eec5e5fa0 R15: 0000000000000004
</TASK>
EXT4-fs error (device loop0): ext4_mb_generate_buddy:1306: group 0, block bitmap and bg descriptor inconsistent: 25 vs 150994969 free clusters
EXT4-fs (loop0): Delayed block allocation failed for inode 15 at logical offset 31 with max blocks 33 with error 28
EXT4-fs (loop0): This should not happen!! Data will be lost
EXT4-fs (loop0): Total free blocks count 0
EXT4-fs (loop0): Free/Dirty block details
EXT4-fs (loop0): free_blocks=2415919104
EXT4-fs (loop0): dirty_blocks=64
EXT4-fs (loop0): Block reservation details
EXT4-fs (loop0): i_reserved_data_blocks=4
---
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.
next prev parent reply other threads:[~2025-12-01 6:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-05 22:08 [syzbot] [ext4?] possible deadlock in ext4_destroy_inline_data (2) syzbot
2025-12-01 6:21 ` syzbot [this message]
2025-12-01 16:16 ` Theodore Tso
2025-12-01 23:17 ` Andreas Dilger
2025-12-01 23:25 ` Darrick J. Wong
2025-12-02 1:56 ` Theodore Tso
2025-12-02 1:14 ` Theodore Tso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=692d33e0.a70a0220.d98e3.017d.GAE@google.com \
--to=syzbot+bb2455d02bda0b5701e3@syzkaller.appspotmail.com \
--cc=adilger.kernel@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.