All of lore.kernel.org
 help / color / mirror / Atom feed
From: syzbot <syzbot+bc7ca0ae4591cb2550f9@syzkaller.appspotmail.com>
To: almaz.alexandrovich@paragon-software.com,
	linux-kernel@vger.kernel.org,  ntfs3@lists.linux.dev,
	syzkaller-bugs@googlegroups.com
Subject: [syzbot] possible deadlock in mi_read
Date: Sat, 01 Oct 2022 06:47:41 -0700	[thread overview]
Message-ID: <000000000000b6f58d05e9f95a0c@google.com> (raw)

Hello,

syzbot found the following issue on:

HEAD commit:    bbed346d5a96 Merge branch 'for-next/core' into for-kernelci
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=111f3904880000
kernel config:  https://syzkaller.appspot.com/x/.config?x=aae2d21e7dd80684
dashboard link: https://syzkaller.appspot.com/bug?extid=bc7ca0ae4591cb2550f9
compiler:       Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2
userspace arch: arm64
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13a49000880000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14ace23f080000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/11078f50b80b/disk-bbed346d.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/398e5f1e6c84/vmlinux-bbed346d.xz

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

loop0: detected capacity change from 0 to 4096
ntfs3: loop0: Different NTFS' sector size (1024) and media sector size (512)
============================================
WARNING: possible recursive locking detected
6.0.0-rc7-syzkaller-18095-gbbed346d5a96 #0 Not tainted
--------------------------------------------
syz-executor243/3030 is trying to acquire lock:
ffff0000caa09ca0 (&ni->ni_lock/4){+.+.}-{3:3}, at: ni_lock fs/ntfs3/ntfs_fs.h:1108 [inline]
ffff0000caa09ca0 (&ni->ni_lock/4){+.+.}-{3:3}, at: mi_read+0x140/0x274 fs/ntfs3/record.c:148

but task is already holding lock:
ffff0000caa0d3e0 (&ni->ni_lock/4){+.+.}-{3:3}, at: ntfs_lookup+0x84/0xe8 fs/ntfs/namei.c:111

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

       CPU0
       ----
  lock(&ni->ni_lock/4);
  lock(&ni->ni_lock/4);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

2 locks held by syz-executor243/3030:
 #0: ffff0000caa0d680 (&type->i_mutex_dir_key#6){++++}-{3:3}, at: inode_lock_shared include/linux/fs.h:766 [inline]
 #0: ffff0000caa0d680 (&type->i_mutex_dir_key#6){++++}-{3:3}, at: lookup_slow+0x34/0x68 fs/namei.c:1701
 #1: ffff0000caa0d3e0 (&ni->ni_lock/4){+.+.}-{3:3}, at: ntfs_lookup+0x84/0xe8 fs/ntfs/namei.c:111

stack backtrace:
CPU: 1 PID: 3030 Comm: syz-executor243 Not tainted 6.0.0-rc7-syzkaller-18095-gbbed346d5a96 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022
Call trace:
 dump_backtrace+0x1c4/0x1f0 arch/arm64/kernel/stacktrace.c:156
 show_stack+0x2c/0x54 arch/arm64/kernel/stacktrace.c:163
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x104/0x16c lib/dump_stack.c:106
 dump_stack+0x1c/0x58 lib/dump_stack.c:113
 __lock_acquire+0x808/0x30a4
 lock_acquire+0x100/0x1f8 kernel/locking/lockdep.c:5666
 __mutex_lock_common+0xd4/0xca8 kernel/locking/mutex.c:603
 __mutex_lock kernel/locking/mutex.c:747 [inline]
 mutex_lock_nested+0x38/0x44 kernel/locking/mutex.c:799
 ni_lock fs/ntfs3/ntfs_fs.h:1108 [inline]
 mi_read+0x140/0x274 fs/ntfs3/record.c:148
 ntfs_read_mft fs/ntfs3/inode.c:69 [inline]
 ntfs_iget5+0x15c/0x138c fs/ntfs3/inode.c:501
 dir_search_u+0x18c/0x1e0 fs/ntfs3/dir.c:264
 ntfs_lookup+0x94/0xe8 fs/ntfs/namei.c:111
 __lookup_slow+0x14c/0x204 fs/namei.c:1685
 lookup_slow+0x44/0x68 fs/namei.c:1702
 walk_component+0x178/0x1b0 fs/namei.c:1993
 lookup_last fs/namei.c:2450 [inline]
 path_lookupat+0xc4/0x208 fs/namei.c:2474
 filename_lookup+0xf8/0x264 fs/namei.c:2503
 user_path_at_empty+0x5c/0x114 fs/namei.c:2876
 user_path_at include/linux/namei.h:57 [inline]
 __do_sys_open_tree fs/namespace.c:2537 [inline]
 __se_sys_open_tree fs/namespace.c:2504 [inline]
 __arm64_sys_open_tree+0x130/0x4a4 fs/namespace.c:2504
 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
 invoke_syscall arch/arm64/kernel/syscall.c:52 [inline]
 el0_svc_common+0x138/0x220 arch/arm64/kernel/syscall.c:142
 do_el0_svc+0x48/0x164 arch/arm64/kernel/syscall.c:206
 el0_svc+0x58/0x150 arch/arm64/kernel/entry-common.c:636
 el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:654
 el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:581


---
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.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

             reply	other threads:[~2022-10-01 13:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-01 13:47 syzbot [this message]
2024-08-23 16:03 ` [syzbot] possible deadlock in mi_read syzbot
2024-09-02 13:17 ` [syzbot] possible fix (linux-ntfs3) syzbot
2024-10-16 10:38 ` [syzbot] check upstream syzbot

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=000000000000b6f58d05e9f95a0c@google.com \
    --to=syzbot+bc7ca0ae4591cb2550f9@syzkaller.appspotmail.com \
    --cc=almaz.alexandrovich@paragon-software.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ntfs3@lists.linux.dev \
    --cc=syzkaller-bugs@googlegroups.com \
    /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.