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