[v6.1] inconsistent lock state in valid_state (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: a356197db198 Linux 6.1.54
git tree: linux-6.1.y
console output: https://syzkaller.appspot.com/x/log.txt?x=14abf3d4680000
kernel config: https://syzkaller.appspot.com/x/.config?x=86626d0659ddddaf
dashboard link: https://syzkaller.appspot.com/bug?extid=3c3cf70f154b5131a759
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1505976c680000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=121c012e680000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/c61f5c33e733/disk-a356197d.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/f3643a8f0c53/vmlinux-a356197d.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a3fcbc0d79f3/bzImage-a356197d.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/5245bd05e16a/mount_0.gz

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

loop0: detected capacity change from 0 to 4096
ntfs3: loop0: Different NTFS' sector size (1024) and media sector size (512)
================================
WARNING: inconsistent lock state
6.1.54-syzkaller #0 Not tainted
--------------------------------
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
syz-executor243/4516 [HC0[0]:SC0[0]:HE1:SE1] takes:
ffffffff81f6cd0e (&obj_hash[i].lock){?.-.}-{2:2}, at: 0x7cb69a5c18001ce5
{IN-HARDIRQ-W} state was registered at:
lock_acquire+0x1f8/0x5a0 kernel/locking/lockdep.c:5661
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0xd1/0x120 kernel/locking/spinlock.c:162
debug_object_activate+0x16a/0x890 lib/debugobjects.c:706
debug_timer_activate kernel/time/timer.c:782 [inline]
add_timer_on+0x348/0x580 kernel/time/timer.c:1234
handle_irq_event_percpu kernel/irq/handle.c:195 [inline]
handle_irq_event+0xa9/0x1e0 kernel/irq/handle.c:210
handle_edge_irq+0x245/0xbf0 kernel/irq/chip.c:819
generic_handle_irq_desc include/linux/irqdesc.h:158 [inline]
handle_irq arch/x86/kernel/irq.c:231 [inline]
__common_interrupt+0xd7/0x1f0 arch/x86/kernel/irq.c:250
common_interrupt+0x9f/0xc0 arch/x86/kernel/irq.c:240
asm_common_interrupt+0x22/0x40 arch/x86/include/asm/idtentry.h:640
console_emit_next_record+0xb70/0xda0 kernel/printk/printk.c:2740
console_unlock+0x278/0x6e0 kernel/printk/printk.c:2860
vprintk_emit+0xd1/0x1f0 kernel/printk/printk.c:2268
_printk+0xd1/0x111 kernel/printk/printk.c:2289
cpu_select_mitigations+0x38/0x8f arch/x86/kernel/cpu/bugs.c:150
arch_cpu_finalize_init+0xf/0x81 arch/x86/kernel/cpu/common.c:2414
start_kernel+0x423/0x53f init/main.c:1101
secondary_startup_64_no_verify+0xcf/0xdb
irq event stamp: 13101
hardirqs last enabled at (13101): [<ffffffff8160442f>] raw_spin_rq_unlock_irq kernel/sched/sched.h:1366 [inline]
hardirqs last enabled at (13101): [<ffffffff8160442f>] finish_lock_switch+0x8f/0x100 kernel/sched/core.c:5000
hardirqs last disabled at (13100): [<ffffffff8a8e66fb>] __schedule+0x31b/0x4330 kernel/sched/core.c:6453
softirqs last enabled at (12378): [<ffffffff8153ee55>] invoke_softirq kernel/softirq.c:445 [inline]
softirqs last enabled at (12378): [<ffffffff8153ee55>] __irq_exit_rcu+0x155/0x240 kernel/softirq.c:650
softirqs last disabled at (12349): [<ffffffff8153ee55>] invoke_softirq kernel/softirq.c:445 [inline]
softirqs last disabled at (12349): [<ffffffff8153ee55>] __irq_exit_rcu+0x155/0x240 kernel/softirq.c:650

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

CPU0
----
lock(&obj_hash[i].lock);
<Interrupt>
lock(&obj_hash[i].lock);

*** DEADLOCK ***

1 lock held by syz-executor243/4516:
#0: ffff88807e14e0e0 (&type->s_umount_key#41/1){+.+.}-{3:3}, at: alloc_super+0x217/0x930 fs/super.c:228

stack backtrace:
CPU: 1 PID: 4516 Comm: syz-executor243 Not tainted 6.1.54-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106
valid_state+0x136/0x1c0 kernel/locking/lockdep.c:3968
mark_lock_irq+0xa8/0xba0 kernel/locking/lockdep.c:4171
mark_lock+0x21c/0x340 kernel/locking/lockdep.c:4627
mark_usage kernel/locking/lockdep.c:4536 [inline]
__lock_acquire+0xc0d/0x1f80 kernel/locking/lockdep.c:5002
lock_acquire+0x1f8/0x5a0 kernel/locking/lockdep.c:5661
__raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]
_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:154
spin_lock include/linux/spinlock.h:350 [inline]
iput_final fs/inode.c:1778 [inline]
iput+0x61e/0x980 fs/inode.c:1815
ntfs_fill_super+0x3cec/0x4500 fs/ntfs3/super.c:1190
get_tree_bdev+0x3fe/0x620 fs/super.c:1355
vfs_get_tree+0x88/0x270 fs/super.c:1562
do_new_mount+0x28b/0xae0 fs/namespace.c:3040
do_mount fs/namespace.c:3383 [inline]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount+0x2d5/0x3c0 fs/namespace.c:3568
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f83c460069a
Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb a6 e8 ee 08 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 49 89 ca b8 a5 00 00 00 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:00007fff19218798 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f83c460069a
RDX: 0000000020000000 RSI: 000000002001f740 RDI: 00007fff192187e0
RBP: 0000000000000004 R08: 00007fff19218820 R09: 000000000001f735
R10: 0000000001000000 R11: 0000000000000286 R12: 00007fff192187e0
R13: 00007fff19218820 R14: 0000000000200000 R15: 0000000000000003
</TASK>
ntfs3: loop0: Mark volume as dirty due to NTFS errors


---
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 bug is already fixed, 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 bug's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the bug is a duplicate of another bug, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[syzbot]

syzbot suspects this issue could be fixed by backporting the following commit:

commit 013ff63b649475f0ee134e2c8d0c8e65284ede50
git tree: upstream
Author: Konstantin Komarov <almaz.ale...@paragon-software.com>
Date: Fri Jun 30 12:17:02 2023 +0000

fs/ntfs3: Add more attributes checks in mi_enum_attr()

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1306a8fb680000

kernel config: https://syzkaller.appspot.com/x/.config?x=86626d0659ddddaf
dashboard link: https://syzkaller.appspot.com/bug?extid=3c3cf70f154b5131a759

syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1505976c680000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=121c012e680000

Please keep in mind that other backports might be required as well.

For information about bisection process see: https://goo.gl/tpsmEJ#bisection