From: syzbot <syzbot+1047e42179f502f2b0a2@syzkaller.appspotmail.com>
To: linux-kernel@vger.kernel.org, reiserfs-devel@vger.kernel.org,
syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] possible deadlock in mnt_want_write_file
Date: Tue, 22 Nov 2022 18:33:39 -0800 [thread overview]
Message-ID: <000000000000cba69705ee1a1d4e@google.com> (raw)
In-Reply-To: <000000000000f250a605ec981d41@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: eb7081409f94 Linux 6.1-rc6
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=155d6d45880000
kernel config: https://syzkaller.appspot.com/x/.config?x=8cdf448d3b35234
dashboard link: https://syzkaller.appspot.com/bug?extid=1047e42179f502f2b0a2
compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1167648d880000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1562d6c5880000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/4a019f55c517/disk-eb708140.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/eb36e890aa8b/vmlinux-eb708140.xz
kernel image: https://storage.googleapis.com/syzbot-assets/feee2c23ec64/bzImage-eb708140.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/aa387a5f9eda/mount_0.gz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+1047e42179f502f2b0a2@syzkaller.appspotmail.com
REISERFS (device loop0): Using tea hash to sort names
REISERFS (device loop0): Created .reiserfs_priv - reserved for xattr storage.
======================================================
WARNING: possible circular locking dependency detected
6.1.0-rc6-syzkaller #0 Not tainted
------------------------------------------------------
syz-executor139/3633 is trying to acquire lock:
ffff888026b18460 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write_file+0x5a/0x1f0 fs/namespace.c:437
but task is already holding lock:
ffff88801f89c090 (&sbi->lock){+.+.}-{3:3}, at: reiserfs_write_lock+0x77/0xd0 fs/reiserfs/lock.c:27
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&sbi->lock){+.+.}-{3:3}:
lock_acquire+0x182/0x3c0 kernel/locking/lockdep.c:5668
__mutex_lock_common+0x1bd/0x26e0 kernel/locking/mutex.c:603
__mutex_lock kernel/locking/mutex.c:747 [inline]
mutex_lock_nested+0x17/0x20 kernel/locking/mutex.c:799
reiserfs_write_lock+0x77/0xd0 fs/reiserfs/lock.c:27
reiserfs_lookup+0x147/0x490 fs/reiserfs/namei.c:364
__lookup_slow+0x266/0x3a0 fs/namei.c:1685
lookup_one_len+0x430/0x690 fs/namei.c:2711
reiserfs_lookup_privroot+0x85/0x1e0 fs/reiserfs/xattr.c:973
reiserfs_fill_super+0x2071/0x24a0 fs/reiserfs/super.c:2174
mount_bdev+0x26c/0x3a0 fs/super.c:1401
legacy_get_tree+0xea/0x180 fs/fs_context.c:610
vfs_get_tree+0x88/0x270 fs/super.c:1531
do_new_mount+0x289/0xad0 fs/namespace.c:3040
do_mount fs/namespace.c:3383 [inline]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount+0x2d3/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
-> #1 (&type->i_mutex_dir_key#6){+.+.}-{3:3}:
lock_acquire+0x182/0x3c0 kernel/locking/lockdep.c:5668
down_write+0x9c/0x270 kernel/locking/rwsem.c:1562
inode_lock include/linux/fs.h:756 [inline]
open_last_lookups fs/namei.c:3478 [inline]
path_openat+0x7b9/0x2df0 fs/namei.c:3710
do_filp_open+0x264/0x4f0 fs/namei.c:3740
do_sys_openat2+0x124/0x4e0 fs/open.c:1310
do_sys_open fs/open.c:1326 [inline]
__do_sys_creat fs/open.c:1402 [inline]
__se_sys_creat fs/open.c:1396 [inline]
__x64_sys_creat+0x11f/0x160 fs/open.c:1396
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
-> #0 (sb_writers#9){.+.+}-{0:0}:
check_prev_add kernel/locking/lockdep.c:3097 [inline]
check_prevs_add kernel/locking/lockdep.c:3216 [inline]
validate_chain+0x1898/0x6ae0 kernel/locking/lockdep.c:3831
__lock_acquire+0x1292/0x1f60 kernel/locking/lockdep.c:5055
lock_acquire+0x182/0x3c0 kernel/locking/lockdep.c:5668
percpu_down_read include/linux/percpu-rwsem.h:51 [inline]
__sb_start_write include/linux/fs.h:1826 [inline]
sb_start_write+0x4d/0x1a0 include/linux/fs.h:1901
mnt_want_write_file+0x5a/0x1f0 fs/namespace.c:437
reiserfs_ioctl+0x16e/0x340 fs/reiserfs/ioctl.c:103
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl+0xfb/0x170 fs/ioctl.c:856
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
other info that might help us debug this:
Chain exists of:
sb_writers#9 --> &type->i_mutex_dir_key#6 --> &sbi->lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&sbi->lock);
lock(&type->i_mutex_dir_key#6);
lock(&sbi->lock);
lock(sb_writers#9);
*** DEADLOCK ***
1 lock held by syz-executor139/3633:
#0: ffff88801f89c090 (&sbi->lock){+.+.}-{3:3}, at: reiserfs_write_lock+0x77/0xd0 fs/reiserfs/lock.c:27
stack backtrace:
CPU: 1 PID: 3633 Comm: syz-executor139 Not tainted 6.1.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
check_noncircular+0x2cc/0x390 kernel/locking/lockdep.c:2177
check_prev_add kernel/locking/lockdep.c:3097 [inline]
check_prevs_add kernel/locking/lockdep.c:3216 [inline]
validate_chain+0x1898/0x6ae0 kernel/locking/lockdep.c:3831
__lock_acquire+0x1292/0x1f60 kernel/locking/lockdep.c:5055
lock_acquire+0x182/0x3c0 kernel/locking/lockdep.c:5668
percpu_down_read include/linux/percpu-rwsem.h:51 [inline]
__sb_start_write include/linux/fs.h:1826 [inline]
sb_start_write+0x4d/0x1a0 include/linux/fs.h:1901
mnt_want_write_file+0x5a/0x1f0 fs/namespace.c:437
reiserfs_ioctl+0x16e/0x340 fs/reiserfs/ioctl.c:103
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl+0xfb/0x170 fs/ioctl.c:856
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:0x7f9c2c672829
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 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffffe9d1ea8 EFLAGS:
next prev parent reply other threads:[~2022-11-23 2:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-03 22:02 [syzbot] possible deadlock in mnt_want_write_file syzbot
2022-11-23 2:33 ` syzbot [this message]
2024-03-09 14:09 ` [syzbot] [reiserfs?] " syzbot
[not found] <20221123084759.5431-1-hdanton@sina.com>
2022-11-23 10:02 ` [syzbot] " syzbot
[not found] <20221123120238.5528-1-hdanton@sina.com>
2022-11-23 19:15 ` syzbot
[not found] <20221123231231.5594-1-hdanton@sina.com>
2022-11-24 6:02 ` 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=000000000000cba69705ee1a1d4e@google.com \
--to=syzbot+1047e42179f502f2b0a2@syzkaller.appspotmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=reiserfs-devel@vger.kernel.org \
--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.