[syzbot] [ext4?] possible deadlock in ext4_destroy_inline_data (2)

[syzbot] [ext4?] possible deadlock in ext4_destroy_inline_data (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    1c353dc8d962 Merge tag 'media/v6.18-2' of git://git.kernel..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14f3a17c580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=e46b8a1c645465a9
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

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

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/f64756196024/disk-1c353dc8.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/c1384c2077fb/vmlinux-1c353dc8.xz
kernel image: https://storage.googleapis.com/syzbot-assets/cfa64f995332/bzImage-1c353dc8.xz

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

======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
kworker/u8:8/30962 is trying to acquire lock:
ffff88807e672708 (&ei->xattr_sem){++++}-{4:4}, at: ext4_write_lock_xattr fs/ext4/xattr.h:157 [inline]
ffff88807e672708 (&ei->xattr_sem){++++}-{4:4}, at: ext4_destroy_inline_data+0x28/0xe0 fs/ext4/inline.c:1787

but task is already holding lock:
ffff8880277c4b98 (&sbi->s_writepages_rwsem){++++}-{0:0}, at: percpu_down_read include/linux/percpu-rwsem.h:77 [inline]
ffff8880277c4b98 (&sbi->s_writepages_rwsem){++++}-{0:0}, at: ext4_writepages_down_read fs/ext4/ext4.h:1796 [inline]
ffff8880277c4b98 (&sbi->s_writepages_rwsem){++++}-{0:0}, at: ext4_writepages+0x1cc/0x350 fs/ext4/inode.c:3024

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&sbi->s_writepages_rwsem){++++}-{0:0}:
       lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868
       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:1796 [inline]
       ext4_writepages+0x1cc/0x350 fs/ext4/inode.c:3024
       do_writepages+0x32e/0x550 mm/page-writeback.c:2604
       __writeback_single_inode+0x145/0xff0 fs/fs-writeback.c:1719
       writeback_single_inode+0x1f9/0x6a0 fs/fs-writeback.c:1840
       write_inode_now+0x160/0x1d0 fs/fs-writeback.c:2903
       iput_final fs/inode.c:1901 [inline]
       iput+0x830/0xc50 fs/inode.c:1966
       ext4_xattr_block_set+0x1fce/0x2ac0 fs/ext4/xattr.c:2199
       ext4_xattr_move_to_block fs/ext4/xattr.c:2664 [inline]
       ext4_xattr_make_inode_space fs/ext4/xattr.c:2739 [inline]
       ext4_expand_extra_isize_ea+0x12da/0x1ea0 fs/ext4/xattr.c:2827
       __ext4_expand_extra_isize+0x30d/0x400 fs/ext4/inode.c:6364
       ext4_try_to_expand_extra_isize fs/ext4/inode.c:6407 [inline]
       __ext4_mark_inode_dirty+0x46c/0x700 fs/ext4/inode.c:6485
       ext4_evict_inode+0x80d/0xee0 fs/ext4/inode.c:254
       evict+0x504/0x9c0 fs/inode.c:810
       ext4_orphan_cleanup+0xc20/0x1460 fs/ext4/orphan.c:470
       __ext4_fill_super fs/ext4/super.c:5617 [inline]
       ext4_fill_super+0x5920/0x61e0 fs/ext4/super.c:5736
       get_tree_bdev_flags+0x40e/0x4d0 fs/super.c:1691
       vfs_get_tree+0x92/0x2b0 fs/super.c:1751
       fc_mount fs/namespace.c:1208 [inline]
       do_new_mount_fc fs/namespace.c:3651 [inline]
       do_new_mount+0x302/0xa10 fs/namespace.c:3727
       do_mount fs/namespace.c:4050 [inline]
       __do_sys_mount fs/namespace.c:4238 [inline]
       __se_sys_mount+0x313/0x410 fs/namespace.c:4215
       do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
       do_syscall_64+0xfa/0xfa0 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+0xb9b/0x2140 kernel/locking/lockdep.c:3908
       __lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5237
       lock_acquire+0x120/0x360 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:1787
       ext4_do_writepages+0x526/0x4610 fs/ext4/inode.c:2810
       ext4_writepages+0x205/0x350 fs/ext4/inode.c:3025
       do_writepages+0x32e/0x550 mm/page-writeback.c:2604
       __writeback_single_inode+0x145/0xff0 fs/fs-writeback.c:1719
       writeback_sb_inodes+0x6c7/0x1010 fs/fs-writeback.c:2015
       wb_writeback+0x43b/0xaf0 fs/fs-writeback.c:2195
       wb_do_writeback fs/fs-writeback.c:2342 [inline]
       wb_workfn+0x409/0xef0 fs/fs-writeback.c:2382
       process_one_work kernel/workqueue.c:3263 [inline]
       process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346
       worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427
       kthread+0x711/0x8a0 kernel/kthread.c:463
       ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158
       ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

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

3 locks held by kworker/u8:8/30962:
 #0: ffff88801c69b948 ((wq_completion)writeback){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3238 [inline]
 #0: ffff88801c69b948 ((wq_completion)writeback){+.+.}-{0:0}, at: process_scheduled_works+0x9b4/0x17b0 kernel/workqueue.c:3346
 #1: ffffc9000b36fba0 ((work_completion)(&(&wb->dwork)->work)){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3239 [inline]
 #1: ffffc9000b36fba0 ((work_completion)(&(&wb->dwork)->work)){+.+.}-{0:0}, at: process_scheduled_works+0x9ef/0x17b0 kernel/workqueue.c:3346
 #2: ffff8880277c4b98 (&sbi->s_writepages_rwsem){++++}-{0:0}, at: percpu_down_read include/linux/percpu-rwsem.h:77 [inline]
 #2: ffff8880277c4b98 (&sbi->s_writepages_rwsem){++++}-{0:0}, at: ext4_writepages_down_read fs/ext4/ext4.h:1796 [inline]
 #2: ffff8880277c4b98 (&sbi->s_writepages_rwsem){++++}-{0:0}, at: ext4_writepages+0x1cc/0x350 fs/ext4/inode.c:3024

stack backtrace:
CPU: 0 UID: 0 PID: 30962 Comm: kworker/u8:8 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
Workqueue: writeback wb_workfn (flush-7:4)
Call Trace:
 <TASK>
 dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
 print_circular_bug+0x2ee/0x310 kernel/locking/lockdep.c:2043
 check_noncircular+0x134/0x160 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+0xb9b/0x2140 kernel/locking/lockdep.c:3908
 __lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5237
 lock_acquire+0x120/0x360 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:1787
 ext4_do_writepages+0x526/0x4610 fs/ext4/inode.c:2810
 ext4_writepages+0x205/0x350 fs/ext4/inode.c:3025
 do_writepages+0x32e/0x550 mm/page-writeback.c:2604
 __writeback_single_inode+0x145/0xff0 fs/fs-writeback.c:1719
 writeback_sb_inodes+0x6c7/0x1010 fs/fs-writeback.c:2015
 wb_writeback+0x43b/0xaf0 fs/fs-writeback.c:2195
 wb_do_writeback fs/fs-writeback.c:2342 [inline]
 wb_workfn+0x409/0xef0 fs/fs-writeback.c:2382
 process_one_work kernel/workqueue.c:3263 [inline]
 process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346
 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427
 kthread+0x711/0x8a0 kernel/kthread.c:463
 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>
EXT4-fs error (device loop4): ext4_mb_generate_buddy:1289: group 0, block bitmap and bg descriptor inconsistent: 25 vs 4128793 free clusters
EXT4-fs (loop4): Delayed block allocation failed for inode 15 at logical offset 0 with max blocks 1 with error 28
EXT4-fs (loop4): This should not happen!! Data will be lost

EXT4-fs (loop4): Total free blocks count 0
EXT4-fs (loop4): Free/Dirty block details
EXT4-fs (loop4): free_blocks=66060288
EXT4-fs (loop4): dirty_blocks=64
EXT4-fs (loop4): Block reservation details
EXT4-fs (loop4): i_reserved_data_blocks=4
EXT4-fs (loop4): Delayed block allocation failed for inode 15 at logical offset 65537 with max blocks 44 with error 28


---
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] [ext4?] possible deadlock in ext4_destroy_inline_data (2)

[syzbot]

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.

Re: [syzbot] [ext4?] possible deadlock in ext4_destroy_inline_data (2)

[Theodore Tso]

This is a flase positive.  The potential deadlock scenarious dentified
by lockdep doesn't happen in real life because one of the locking
dependency chain happens when we are doing orphan file cleanup while
we are also eneding to expand an inode's extra size:

> -> #1 (&sbi->s_writepages_rwsem){++++}-{0:0}:
>        lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868
>        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:1796 [inline]
>        ext4_writepages+0x1cc/0x350 fs/ext4/inode.c:3024
>        do_writepages+0x32e/0x550 mm/page-writeback.c:2604
>        __writeback_single_inode+0x145/0xff0 fs/fs-writeback.c:1719
>        writeback_single_inode+0x1f9/0x6a0 fs/fs-writeback.c:1840
>        write_inode_now+0x160/0x1d0 fs/fs-writeback.c:2903
>        iput_final fs/inode.c:1901 [inline]
>        iput+0x830/0xc50 fs/inode.c:1966
>        ext4_xattr_block_set+0x1fce/0x2ac0 fs/ext4/xattr.c:2199
>        ext4_xattr_move_to_block fs/ext4/xattr.c:2664 [inline]
>        ext4_xattr_make_inode_space fs/ext4/xattr.c:2739 [inline]
>        ext4_expand_extra_isize_ea+0x12da/0x1ea0 fs/ext4/xattr.c:2827
>        __ext4_expand_extra_isize+0x30d/0x400 fs/ext4/inode.c:6364
>        ext4_try_to_expand_extra_isize fs/ext4/inode.c:6407 [inline]
>        __ext4_mark_inode_dirty+0x46c/0x700 fs/ext4/inode.c:6485
>        ext4_evict_inode+0x80d/0xee0 fs/ext4/inode.c:254
>        evict+0x504/0x9c0 fs/inode.c:810
>        ext4_orphan_cleanup+0xc20/0x1460 fs/ext4/orphan.c:470
>        __ext4_fill_super fs/ext4/super.c:5617 [inline]
>        ext4_fill_super+0x5920/0x61e0 fs/ext4/super.c:5736
    ....

And the other is in the inode writeback path:

> -> #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+0xb9b/0x2140 kernel/locking/lockdep.c:3908
>        __lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5237
>        lock_acquire+0x120/0x360 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:1787
>        ext4_do_writepages+0x526/0x4610 fs/ext4/inode.c:2810
>        ext4_writepages+0x205/0x350 fs/ext4/inode.c:3025
>        do_writepages+0x32e/0x550 mm/page-writeback.c:2604
>        __writeback_single_inode+0x145/0xff0 fs/fs-writeback.c:1719
>        writeback_sb_inodes+0x6c7/0x1010 fs/fs-writeback.c:2015
>        wb_writeback+0x43b/0xaf0 fs/fs-writeback.c:2195
    ...

So the first happens while we are mounting the file system, and the
second happens after the file system is mounted and we have written to
a file.

That being said, we probably should just not try to expand the inode's
extra size while evicting the inode.  In practice we don't actually do
this since we haven't expanded the inode's extra size space in over a
decade, and so this only happens in a debugging mount option that
syzbot helpfully uses, and not in real life.

Also, there's no real point in doing this on the evict path,
especially if the inode is about to be released as part of the
eviction.

						- Ted

Re: [syzbot] [ext4?] possible deadlock in ext4_destroy_inline_data (2)

[Andreas Dilger]

On Dec 1, 2025, at 9:16 AM, Theodore Tso <tytso@mit.edu> wrote:
> 
> That being said, we probably should just not try to expand the inode's
> extra size while evicting the inode.  In practice we don't actually do
> this since we haven't expanded the inode's extra size space in over a
> decade, and so this only happens in a debugging mount option that
> syzbot helpfully uses, and not in real life.

I think we would regret removing this if/when we *do* expand the inode
size.  We used this functionality to upgrade filesystems online when
i_projid was first added and users suddenly wanted to use project quotas.
If we need some new inode field in the future it will be good to have it.

> Also, there's no real point in doing this on the evict path,
> especially if the inode is about to be released as part of the
> eviction.

This could check in ext4_orphan_cleanup()->ext4_evict_inode() path
that this is orphan cleanup with EXT4_ORPHAN_FS and skip the expansion?
As you write, it doesn't make sense to do that when the file is being
deleted anyway.  Something like the following, which adds unlikely() to
that branch since it may happen only once or never in the lifetime of
any inode:

Cheers, Andreas
---
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index e99306a8f47c..ae48748decc5 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -6481,7 +6490,8 @@ int __ext4_mark_inode_dirty(handle_t *handle,
 	if (err)
 		goto out;
-	if (EXT4_I(inode)->i_extra_isize < sbi->s_want_extra_isize)
+	if (unlikely(EXT4_I(inode)->i_extra_isize < sbi->s_want_extra_isize &&
+		     !(sbi->s_mount_state & EXT4_ORPHAN_FS)))
 		ext4_try_to_expand_extra_isize(inode, sbi->s_want_extra_isize,
 					       iloc, handle);

Re: [syzbot] [ext4?] possible deadlock in ext4_destroy_inline_data (2)

[Darrick J. Wong]

On Mon, Dec 01, 2025 at 04:17:02PM -0700, Andreas Dilger wrote:
> On Dec 1, 2025, at 9:16 AM, Theodore Tso <tytso@mit.edu> wrote:
> > 
> > That being said, we probably should just not try to expand the inode's
> > extra size while evicting the inode.  In practice we don't actually do
> > this since we haven't expanded the inode's extra size space in over a
> > decade, and so this only happens in a debugging mount option that
> > syzbot helpfully uses, and not in real life.
> 
> I think we would regret removing this if/when we *do* expand the inode
> size.  We used this functionality to upgrade filesystems online when
> i_projid was first added and users suddenly wanted to use project quotas.
> If we need some new inode field in the future it will be good to have it.

Or expand extra_isize only when someone tries to set an inode field that
actually requires it?  e.g. whenever setting the project id?

--D

> > Also, there's no real point in doing this on the evict path,
> > especially if the inode is about to be released as part of the
> > eviction.
> 
> This could check in ext4_orphan_cleanup()->ext4_evict_inode() path
> that this is orphan cleanup with EXT4_ORPHAN_FS and skip the expansion?
> As you write, it doesn't make sense to do that when the file is being
> deleted anyway.  Something like the following, which adds unlikely() to
> that branch since it may happen only once or never in the lifetime of
> any inode:
> 
> Cheers, Andreas
> ---
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index e99306a8f47c..ae48748decc5 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -6481,7 +6490,8 @@ int __ext4_mark_inode_dirty(handle_t *handle,
>  	if (err)
>  		goto out;
> -	if (EXT4_I(inode)->i_extra_isize < sbi->s_want_extra_isize)
> +	if (unlikely(EXT4_I(inode)->i_extra_isize < sbi->s_want_extra_isize &&
> +		     !(sbi->s_mount_state & EXT4_ORPHAN_FS)))
>  		ext4_try_to_expand_extra_isize(inode, sbi->s_want_extra_isize,
>  					       iloc, handle);
> 
> 
> 
> 
> 
> 

Re: [syzbot] [ext4?] possible deadlock in ext4_destroy_inline_data (2)

[Theodore Tso]

On Mon, Dec 01, 2025 at 04:17:02PM -0700, Andreas Dilger wrote:
> I think we would regret removing this if/when we *do* expand the inode
> size.  We used this functionality to upgrade filesystems online when
> i_projid was first added and users suddenly wanted to use project quotas.
> If we need some new inode field in the future it will be good to have it.

I wasn't proposing to remove the code.  I was just saying that from
the perspective of prioritization, it's not a high priority for me to
pay attention to syzbot complaints that involve this code path ---
just as it's not high priority for me to pay attentiont to syzbot
complaints that involve assuming that you should allow random
untrusted users to mount maliciously corrupted file systems --- we
should be encouraging users who want to allow people who allow their
users to pick up random USB sticks scattered in the parking lot by the
CIA or MSS and automount them as root to use fuse2fs instead.

(And by the way, it's not hard to prohibit USB sticks from being
allowed to be attached and thus making it impossible for them to be
mounted; that's how we protect things at $WORK for all desktop
systems, and ChromeOS has knobs which allow enterprise administrators
to prevent this.  It's just basically a good idea if you are a
paranoid adminstrator and are worried about nation-state attacks...
It's also makes life much easier if you are an intelligence agency and
you are worried about Snowden-style exfiltration threats; if they have
to send it out over the network, you can at least do more to detect
such activities.  :-)

In this particular syzbot complaint, it requires using a debugging
mount options that is in practice never used in the real world *and* a
malciously corrupted file system.  So it's not super high priority for
me to fix, but if we have a quick and easy fix, we should definitely
go for it, if only to shut up syzbot --- not that it will make any
difference for production use cases assuming sensible system administrators.

> This could check in ext4_orphan_cleanup()->ext4_evict_inode() path
> that this is orphan cleanup with EXT4_ORPHAN_FS and skip the expansion?
> As you write, it doesn't make sense to do that when the file is being
> deleted anyway.  Something like the following, which adds unlikely() to
> that branch since it may happen only once or never in the lifetime of
> any inode:

Something like this, but we should also skip trying to expand the
inode if i_links_count is zero.  That way, we won't try to expand an
inode if we are running rm -rf on a directory hierarchy composed of
hundreds or thousands of inodes where trying to expand the inode is a
complete waste of time.  :-)

					- Ted

Re: [syzbot] [ext4?] possible deadlock in ext4_destroy_inline_data (2)

[Theodore Tso]

On Mon, Dec 01, 2025 at 03:25:52PM -0800, Darrick J. Wong wrote:
> 
> Or expand extra_isize only when someone tries to set an inode field that
> actually requires it?  e.g. whenever setting the project id?

Or when adding/removing/changing an extended attribute, especially one
stored in the inode table, since that's when we need to make sure
we've left room the expanded inode.

Certainly if all we are doing is, say, updating the atime, trying to
move out an extended attribute to make room for an inode field that
might never get used is kind of a waste.

We just haven't really focused on this much, since we haven't needed
to expand the inode in many years.  But if someone wants to work on
it, that would be great!

					- Ted