[v6.6] possible deadlock in mi_read

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: e617101e5626 Linux 6.6.110
git tree: linux-6.6.y
console output: https://syzkaller.appspot.com/x/log.txt?x=169da1e2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=12606d4b8832c7e4
dashboard link: https://syzkaller.appspot.com/bug?extid=bc688b7a7970327eef2d
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/5e096b5ec298/disk-e617101e.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/074307bb1464/vmlinux-e617101e.xz
kernel image: https://storage.googleapis.com/syzbot-assets/68e0d6ffb47c/bzImage-e617101e.xz

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

============================================
WARNING: possible recursive locking detected
syzkaller #0 Not tainted
--------------------------------------------
syz.7.2594/13031 is trying to acquire lock:
ffff88805d0f6840 (&ni->ni_lock#3/5){+.+.}-{3:3}, at: ni_lock fs/ntfs3/ntfs_fs.h:1119 [inline]
ffff88805d0f6840 (&ni->ni_lock#3/5){+.+.}-{3:3}, at: mi_read+0x2d4/0x5a0 fs/ntfs3/record.c:148

but task is already holding lock:
ffff888057f59e80 (&ni->ni_lock#3/5){+.+.}-{3:3}, at: ni_lock fs/ntfs3/ntfs_fs.h:1119 [inline]
ffff888057f59e80 (&ni->ni_lock#3/5){+.+.}-{3:3}, at: ntfs_rename+0x69d/0xb30 fs/ntfs3/namei.c:329

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

CPU0
----
lock(&ni->ni_lock#3/5);
lock(&ni->ni_lock#3/5);

*** DEADLOCK ***

May be due to missing lock nesting notation

5 locks held by syz.7.2594/13031:
#0: ffff88805c344418 (sb_writers#23){.+.+}-{0:0}, at: mnt_want_write+0x41/0x90 fs/namespace.c:403
#1: ffff88805d0f5c30 (&type->i_mutex_dir_key#19/1){+.+.}-{3:3}, at: lock_rename include/linux/fs.h:-1 [inline]
#1: ffff88805d0f5c30 (&type->i_mutex_dir_key#19/1){+.+.}-{3:3}, at: do_renameat2+0x427/0xc70 fs/namei.c:4964
#2: ffff88805d0f5980 (&ni->ni_lock/6){+.+.}-{3:3}, at: ni_lock_dir fs/ntfs3/ntfs_fs.h:1124 [inline]
#2: ffff88805d0f5980 (&ni->ni_lock/6){+.+.}-{3:3}, at: ntfs_rename+0x687/0xb30 fs/ntfs3/namei.c:328
#3: ffff888057f59e80 (&ni->ni_lock#3/5){+.+.}-{3:3}, at: ni_lock fs/ntfs3/ntfs_fs.h:1119 [inline]
#3: ffff888057f59e80 (&ni->ni_lock#3/5){+.+.}-{3:3}, at: ntfs_rename+0x69d/0xb30 fs/ntfs3/namei.c:329
#4: ffff88802b5fc128 (&wnd->rw_lock/1){+.+.}-{3:3}, at: ntfs_look_free_mft+0x164/0xd40 fs/ntfs3/fsntfs.c:571

stack backtrace:
CPU: 1 PID: 13031 Comm: syz.7.2594 Not tainted syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
Call Trace:
<TASK>
dump_stack_lvl+0x16c/0x230 lib/dump_stack.c:106
check_deadlock kernel/locking/lockdep.c:3062 [inline]
validate_chain kernel/locking/lockdep.c:3856 [inline]
__lock_acquire+0x5d40/0x7c80 kernel/locking/lockdep.c:5137
lock_acquire+0x197/0x410 kernel/locking/lockdep.c:5754
__mutex_lock_common kernel/locking/mutex.c:603 [inline]
__mutex_lock+0x129/0xcc0 kernel/locking/mutex.c:747
ni_lock fs/ntfs3/ntfs_fs.h:1119 [inline]
mi_read+0x2d4/0x5a0 fs/ntfs3/record.c:148
mi_format_new+0x1a3/0x600 fs/ntfs3/record.c:419
ni_add_subrecord+0xd0/0x440 fs/ntfs3/frecord.c:374
ntfs_look_free_mft+0x6a8/0xd40 fs/ntfs3/fsntfs.c:715
ni_create_attr_list+0x904/0x1370 fs/ntfs3/frecord.c:878
ni_ins_attr_ext+0x315/0x9c0 fs/ntfs3/frecord.c:976
ni_insert_attr fs/ntfs3/frecord.c:1143 [inline]
ni_insert_resident fs/ntfs3/frecord.c:1527 [inline]
ni_add_name+0x6e0/0xc90 fs/ntfs3/frecord.c:3042
ni_rename+0x4b/0x100 fs/ntfs3/frecord.c:3081
ntfs_rename+0x6dc/0xb30 fs/ntfs3/namei.c:333
vfs_rename+0xb96/0xec0 fs/namei.c:4872
do_renameat2+0x8a1/0xc70 fs/namei.c:5025
__do_sys_rename fs/namei.c:5071 [inline]
__se_sys_rename fs/namei.c:5069 [inline]
__x64_sys_rename+0x86/0x90 fs/namei.c:5069
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
RIP: 0033:0x7f6b81f8eec9
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:00007f6b82eb9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000052
RAX: ffffffffffffffda RBX: 00007f6b821e6090 RCX: 00007f6b81f8eec9
RDX: 0000000000000000 RSI: 0000200000000f40 RDI: 00002000000003c0
RBP: 00007f6b82011f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f6b821e6128 R14: 00007f6b821e6090 R15: 00007ffe8100e368
</TASK>


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