possible deadlock in mnt_want_write_file

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 9d5c0b3a8e1a Linux 4.14.295
git tree: linux-4.14.y
console output: https://syzkaller.appspot.com/x/log.txt?x=15aebc92880000
kernel config: https://syzkaller.appspot.com/x/.config?x=746c079015a92425
dashboard link: https://syzkaller.appspot.com/bug?extid=06a02ff61d40cdf900b1
compiler: gcc version 10.2.1 20210110 (Debian 10.2.1-6)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1177b348880000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13fa0ecc880000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/ed6fcf5895a2/disk-9d5c0b3a.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/341aa3534116/vmlinux-9d5c0b3a.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/889cf9d5dc2f/mount_0.gz

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

REISERFS (device loop0): journal params: device loop0, size 512, journal first block 18, max trans len 256, max batch 225, max commit age 30, max trans age 30
REISERFS (device loop0): checking transaction log (loop0)
REISERFS (device loop0): Using rupasov hash to sort names
REISERFS (device loop0): Created .reiserfs_priv - reserved for xattr storage.
======================================================
WARNING: possible circular locking dependency detected
4.14.295-syzkaller #0 Not tainted
------------------------------------------------------
syz-executor148/7984 is trying to acquire lock:
(sb_writers#10){.+.+}, at: [<ffffffff818e09ad>] sb_start_write include/linux/fs.h:1551 [inline]
(sb_writers#10){.+.+}, at: [<ffffffff818e09ad>] mnt_want_write_file+0xfd/0x3b0 fs/namespace.c:497

but task is already holding lock:
(&sbi->lock){+.+.}, at: [<ffffffff81b3e145>] reiserfs_write_lock+0x75/0xf0 fs/reiserfs/lock.c:27

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (&sbi->lock){+.+.}:
__mutex_lock_common kernel/locking/mutex.c:756 [inline]
__mutex_lock+0xc4/0x1310 kernel/locking/mutex.c:893
reiserfs_write_lock+0x75/0xf0 fs/reiserfs/lock.c:27
reiserfs_lookup+0x130/0x400 fs/reiserfs/namei.c:363
lookup_real fs/namei.c:1555 [inline]
__lookup_hash fs/namei.c:1575 [inline]
__lookup_hash+0x1bb/0x270 fs/namei.c:1563
lookup_one_len+0x279/0x3a0 fs/namei.c:2539
reiserfs_lookup_privroot+0x92/0x270 fs/reiserfs/xattr.c:970
reiserfs_fill_super+0x1d12/0x2990 fs/reiserfs/super.c:2187
mount_bdev+0x2b3/0x360 fs/super.c:1134
mount_fs+0x92/0x2a0 fs/super.c:1237
vfs_kern_mount.part.0+0x5b/0x470 fs/namespace.c:1046
vfs_kern_mount fs/namespace.c:1036 [inline]
do_new_mount fs/namespace.c:2572 [inline]
do_mount+0xe65/0x2a30 fs/namespace.c:2905
SYSC_mount fs/namespace.c:3121 [inline]
SyS_mount+0xa8/0x120 fs/namespace.c:3098
do_syscall_64+0x1d5/0x640 arch/x86/entry/common.c:292
entry_SYSCALL_64_after_hwframe+0x46/0xbb

-> #1 (&type->i_mutex_dir_key#7){+.+.}:
down_write+0x34/0x90 kernel/locking/rwsem.c:54
inode_lock include/linux/fs.h:719 [inline]
chmod_common+0x12e/0x390 fs/open.c:545
SYSC_fchmod fs/open.c:570 [inline]
SyS_fchmod+0xbe/0x110 fs/open.c:563
do_syscall_64+0x1d5/0x640 arch/x86/entry/common.c:292
entry_SYSCALL_64_after_hwframe+0x46/0xbb

-> #0 (sb_writers#10){.+.+}:
lock_acquire+0x170/0x3f0 kernel/locking/lockdep.c:3998
percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36 [inline]
percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
__sb_start_write+0x64/0x260 fs/super.c:1342
sb_start_write include/linux/fs.h:1551 [inline]
mnt_want_write_file+0xfd/0x3b0 fs/namespace.c:497
reiserfs_ioctl+0x18e/0x8b0 fs/reiserfs/ioctl.c:110
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:500 [inline]
do_vfs_ioctl+0x75a/0xff0 fs/ioctl.c:684
SYSC_ioctl fs/ioctl.c:701 [inline]
SyS_ioctl+0x7f/0xb0 fs/ioctl.c:692
do_syscall_64+0x1d5/0x640 arch/x86/entry/common.c:292
entry_SYSCALL_64_after_hwframe+0x46/0xbb

other info that might help us debug this:

Chain exists of:
sb_writers#10 --> &type->i_mutex_dir_key#7 --> &sbi->lock

Possible unsafe locking scenario:

CPU0 CPU1
---- ----
lock(&sbi->lock);
lock(&type->i_mutex_dir_key#7);
lock(&sbi->lock);
lock(sb_writers#10);

*** DEADLOCK ***

1 lock held by syz-executor148/7984:
#0: (&sbi->lock){+.+.}, at: [<ffffffff81b3e145>] reiserfs_write_lock+0x75/0xf0 fs/reiserfs/lock.c:27

stack backtrace:
CPU: 0 PID: 7984 Comm: syz-executor148 Not tainted 4.14.295-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x1b2/0x281 lib/dump_stack.c:58
print_circular_bug.constprop.0.cold+0x2d7/0x41e kernel/locking/lockdep.c:1258
check_prev_add kernel/locking/lockdep.c:1905 [inline]
check_prevs_add kernel/locking/lockdep.c:2022 [inline]
validate_chain kernel/locking/lockdep.c:2464 [inline]
__lock_acquire+0x2e0e/0x3f20 kernel/locking/lockdep.c:3491
lock_acquire+0x170/0x3f0 kernel/locking/lockdep.c:3998
percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36 [inline]
percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
__sb_start_write+0x64/0x260 fs/super.c:1342
sb_start_write include/linux/fs.h:1551 [inline]
mnt_want_write_file+0xfd/0x3b0 fs/namespace.c:497
reiserfs_ioctl+0x18e/0x8b0 fs/reiserfs/ioctl.c:110
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:500 [inline]
do_vfs_ioctl+0x75a/0xff0 fs/ioctl.c:684
SYSC_ioctl fs/ioctl.c:701 [inline]
SyS_ioctl+0x7f/0xb0 fs/ioctl.c:692
do_syscall_64+0x1d5/0x640 arch/x86/entry/common.c:292
entry_SYSCALL_64_after_hwframe+0x46/0xbb
RIP: 0033:0x7f20fd90d899
RSP: 002b:00007ffcc0a48a98 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f20fd90d899
RDX: 0000000000000000 RSI: 0000000040087602 RDI: 0000000000000005
RBP: 0000000000000000 R08: 00007f20fd97bec0 R09: 00007f20fd97bec0
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffcc0a48ac0
R13: 0000000000000000 R14: 431bde82d7b634db R15: 0000000000000000


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