[syzbot] [fs?] possible deadlock in __simple_recursive_removal

[syzbot] [fs?] possible deadlock in __simple_recursive_removal

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    50c8770a42fa Add linux-next specific files for 20250702
git tree:       linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=152d348c580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=70c16e4e191115d4
dashboard link: https://syzkaller.appspot.com/bug?extid=6d7771315ecb9233f395
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=106bd770580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=164b048c580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/3d4ef6bedc5b/disk-50c8770a.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/15b7565dc0ef/vmlinux-50c8770a.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3b397342a62b/bzImage-50c8770a.xz

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

============================================
WARNING: possible recursive locking detected
6.16.0-rc4-next-20250702-syzkaller #0 Not tainted
--------------------------------------------
syz-executor365/5837 is trying to acquire lock:
ffff8880792cc650 (&sb->s_type->i_mutex_key#15){+.+.}-{4:4}, at: inode_lock include/linux/fs.h:869 [inline]
ffff8880792cc650 (&sb->s_type->i_mutex_key#15){+.+.}-{4:4}, at: __simple_recursive_removal+0x95/0x510 fs/libfs.c:614

but task is already holding lock:
ffff888027bf0148 (&sb->s_type->i_mutex_key#15){+.+.}-{4:4}, at: inode_lock include/linux/fs.h:869 [inline]
ffff888027bf0148 (&sb->s_type->i_mutex_key#15){+.+.}-{4:4}, at: bm_entry_write+0x289/0x540 fs/binfmt_misc.c:737

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&sb->s_type->i_mutex_key#15);
  lock(&sb->s_type->i_mutex_key#15);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

2 locks held by syz-executor365/5837:
 #0: ffff88807e5fc428 (sb_writers#8){.+.+}-{0:0}, at: file_start_write include/linux/fs.h:3098 [inline]
 #0: ffff88807e5fc428 (sb_writers#8){.+.+}-{0:0}, at: vfs_write+0x211/0xa90 fs/read_write.c:682
 #1: ffff888027bf0148 (&sb->s_type->i_mutex_key#15){+.+.}-{4:4}, at: inode_lock include/linux/fs.h:869 [inline]
 #1: ffff888027bf0148 (&sb->s_type->i_mutex_key#15){+.+.}-{4:4}, at: bm_entry_write+0x289/0x540 fs/binfmt_misc.c:737

stack backtrace:
CPU: 0 UID: 0 PID: 5837 Comm: syz-executor365 Not tainted 6.16.0-rc4-next-20250702-syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
 <TASK>
 dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
 print_deadlock_bug+0x28b/0x2a0 kernel/locking/lockdep.c:3044
 check_deadlock kernel/locking/lockdep.c:3096 [inline]
 validate_chain+0x1a3f/0x2140 kernel/locking/lockdep.c:3898
 __lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5240
 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1577
 inode_lock include/linux/fs.h:869 [inline]
 __simple_recursive_removal+0x95/0x510 fs/libfs.c:614
 remove_binfmt_handler fs/binfmt_misc.c:694 [inline]
 bm_entry_write+0x4f7/0x540 fs/binfmt_misc.c:749
 vfs_write+0x27e/0xa90 fs/read_write.c:684
 ksys_write+0x145/0x250 fs/read_write.c:738
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f147e7aa369
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffed0db9fa8 EFLAGS: 00000246 ORIG_RAX


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

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] [fs?] possible deadlock in __simple_recursive_removal

[Al Viro]

On Wed, Jul 02, 2025 at 11:04:33AM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    50c8770a42fa Add linux-next specific files for 20250702
> git tree:       linux-next
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=152d348c580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=70c16e4e191115d4
> dashboard link: https://syzkaller.appspot.com/bug?extid=6d7771315ecb9233f395
> 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=106bd770580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=164b048c580000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/3d4ef6bedc5b/disk-50c8770a.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/15b7565dc0ef/vmlinux-50c8770a.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/3b397342a62b/bzImage-50c8770a.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+6d7771315ecb9233f395@syzkaller.appspotmail.com
> 
> ============================================
> WARNING: possible recursive locking detected
> 6.16.0-rc4-next-20250702-syzkaller #0 Not tainted

False positive.  locked_recursive_removal() is called with ->i_rwsem
on the victim's parent.  It will grab and release ->i_rwsem on
descendents of victim and victim itself (never more than one held
simultaneously) and it is used only on filesystems where we never
change the tree topology.  So the normal ordering of ->i_rwsem is
upheld there.

Proper annotations would be to have the lock on parent grabbed with
I_MUTEX_PARENT as class...