[v6.1] possible deadlock in delete_one_xattr

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 117ac406ba90 Linux 6.1.105
git tree: linux-6.1.y
console output: https://syzkaller.appspot.com/x/log.txt?x=1168cdd3980000
kernel config: https://syzkaller.appspot.com/x/.config?x=b2a32e4747745ef9
dashboard link: https://syzkaller.appspot.com/bug?extid=9ab0d415d5815e5d7bf7
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/586baf9cee9c/disk-117ac406.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/0db196fab312/vmlinux-117ac406.xz
kernel image: https://storage.googleapis.com/syzbot-assets/26e336dd760c/bzImage-117ac406.xz

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

======================================================
WARNING: possible circular locking dependency detected
6.1.105-syzkaller #0 Not tainted
------------------------------------------------------
syz-executor/4557 is trying to acquire lock:
ffff888071b45fa0 (&type->i_mutex_dir_key#12/2){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:793 [inline]
ffff888071b45fa0 (&type->i_mutex_dir_key#12/2){+.+.}-{3:3}, at: xattr_rmdir fs/reiserfs/xattr.c:106 [inline]
ffff888071b45fa0 (&type->i_mutex_dir_key#12/2){+.+.}-{3:3}, at: delete_one_xattr+0x102/0x2f0 fs/reiserfs/xattr.c:338

but task is already holding lock:
ffff888071b45900 (&type->i_mutex_dir_key#12/3){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:793 [inline]
ffff888071b45900 (&type->i_mutex_dir_key#12/3){+.+.}-{3:3}, at: reiserfs_for_each_xattr+0x9a4/0xb40 fs/reiserfs/xattr.c:309

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (&type->i_mutex_dir_key#12/3){+.+.}-{3:3}:
lock_acquire+0x1f8/0x5a0 kernel/locking/lockdep.c:5662
down_write_nested+0x39/0x60 kernel/locking/rwsem.c:1689
inode_lock_nested include/linux/fs.h:793 [inline]
open_xa_root fs/reiserfs/xattr.c:127 [inline]
open_xa_dir+0x132/0x610 fs/reiserfs/xattr.c:152
xattr_lookup+0x24/0x280 fs/reiserfs/xattr.c:395
reiserfs_xattr_set_handle+0xf8/0xdc0 fs/reiserfs/xattr.c:533
reiserfs_xattr_set+0x44e/0x570 fs/reiserfs/xattr.c:633
__vfs_setxattr+0x3e7/0x420 fs/xattr.c:182
__vfs_setxattr_noperm+0x12a/0x5e0 fs/xattr.c:216
vfs_setxattr+0x21d/0x420 fs/xattr.c:309
ovl_do_setxattr fs/overlayfs/overlayfs.h:252 [inline]
ovl_setxattr fs/overlayfs/overlayfs.h:264 [inline]
ovl_make_workdir fs/overlayfs/super.c:1435 [inline]
ovl_get_workdir+0xdfe/0x17b0 fs/overlayfs/super.c:1539
ovl_fill_super+0x1b85/0x2a20 fs/overlayfs/super.c:2095
mount_nodev+0x52/0xe0 fs/super.c:1489
legacy_get_tree+0xeb/0x180 fs/fs_context.c:632
vfs_get_tree+0x88/0x270 fs/super.c:1573
do_new_mount+0x2ba/0xb40 fs/namespace.c:3051
do_mount fs/namespace.c:3394 [inline]
__do_sys_mount fs/namespace.c:3602 [inline]
__se_sys_mount+0x2d5/0x3c0 fs/namespace.c:3579
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x3b/0xb0 arch/x86/entry/common.c:81
entry_SYSCALL_64_after_hwframe+0x68/0xd2

-> #1 (&type->i_mutex_dir_key#12){++++}-{3:3}:
lock_acquire+0x1f8/0x5a0 kernel/locking/lockdep.c:5662
down_write+0x36/0x60 kernel/locking/rwsem.c:1573
inode_lock include/linux/fs.h:758 [inline]
vfs_rename+0x814/0x10f0 fs/namei.c:4841
do_renameat2+0xde0/0x1440 fs/namei.c:5029
__do_sys_renameat2 fs/namei.c:5062 [inline]
__se_sys_renameat2 fs/namei.c:5059 [inline]
__x64_sys_renameat2+0xce/0xe0 fs/namei.c:5059
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x3b/0xb0 arch/x86/entry/common.c:81
entry_SYSCALL_64_after_hwframe+0x68/0xd2

-> #0 (&type->i_mutex_dir_key#12/2){+.+.}-{3:3}:
check_prev_add kernel/locking/lockdep.c:3090 [inline]
check_prevs_add kernel/locking/lockdep.c:3209 [inline]
validate_chain+0x1661/0x5950 kernel/locking/lockdep.c:3825
__lock_acquire+0x125b/0x1f80 kernel/locking/lockdep.c:5049
lock_acquire+0x1f8/0x5a0 kernel/locking/lockdep.c:5662
down_write_nested+0x39/0x60 kernel/locking/rwsem.c:1689
inode_lock_nested include/linux/fs.h:793 [inline]
xattr_rmdir fs/reiserfs/xattr.c:106 [inline]
delete_one_xattr+0x102/0x2f0 fs/reiserfs/xattr.c:338
reiserfs_for_each_xattr+0x9b2/0xb40 fs/reiserfs/xattr.c:311
reiserfs_delete_xattrs+0x1b/0x80 fs/reiserfs/xattr.c:364
reiserfs_evict_inode+0x20c/0x460 fs/reiserfs/inode.c:53
evict+0x2a4/0x620 fs/inode.c:666
d_delete_notify include/linux/fsnotify.h:267 [inline]
vfs_rmdir+0x381/0x4b0 fs/namei.c:4206
do_rmdir+0x3a2/0x590 fs/namei.c:4254
__do_sys_unlinkat fs/namei.c:4434 [inline]
__se_sys_unlinkat fs/namei.c:4428 [inline]
__x64_sys_unlinkat+0xdc/0xf0 fs/namei.c:4428
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x3b/0xb0 arch/x86/entry/common.c:81
entry_SYSCALL_64_after_hwframe+0x68/0xd2

other info that might help us debug this:

Chain exists of:
&type->i_mutex_dir_key#12/2 --> &type->i_mutex_dir_key#12 --> &type->i_mutex_dir_key#12/3

Possible unsafe locking scenario:

CPU0 CPU1
---- ----
lock(&type->i_mutex_dir_key#12/3);
lock(&type->i_mutex_dir_key#12);
lock(&type->i_mutex_dir_key#12/3);
lock(&type->i_mutex_dir_key#12/2);

*** DEADLOCK ***

3 locks held by syz-executor/4557:
#0: ffff88805e30a460 (sb_writers#17){.+.+}-{0:0}, at: mnt_want_write+0x3b/0x80 fs/namespace.c:393
#1: ffff888071b44520 (&type->i_mutex_dir_key#12/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:793 [inline]
#1: ffff888071b44520 (&type->i_mutex_dir_key#12/1){+.+.}-{3:3}, at: do_rmdir+0x251/0x590 fs/namei.c:4241
#2: ffff888071b45900 (&type->i_mutex_dir_key#12/3){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:793 [inline]
#2: ffff888071b45900 (&type->i_mutex_dir_key#12/3){+.+.}-{3:3}, at: reiserfs_for_each_xattr+0x9a4/0xb40 fs/reiserfs/xattr.c:309

stack backtrace:
CPU: 1 PID: 4557 Comm: syz-executor Not tainted 6.1.105-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106
check_noncircular+0x2fa/0x3b0 kernel/locking/lockdep.c:2170
check_prev_add kernel/locking/lockdep.c:3090 [inline]
check_prevs_add kernel/locking/lockdep.c:3209 [inline]
validate_chain+0x1661/0x5950 kernel/locking/lockdep.c:3825
__lock_acquire+0x125b/0x1f80 kernel/locking/lockdep.c:5049
lock_acquire+0x1f8/0x5a0 kernel/locking/lockdep.c:5662
down_write_nested+0x39/0x60 kernel/locking/rwsem.c:1689
inode_lock_nested include/linux/fs.h:793 [inline]
xattr_rmdir fs/reiserfs/xattr.c:106 [inline]
delete_one_xattr+0x102/0x2f0 fs/reiserfs/xattr.c:338
reiserfs_for_each_xattr+0x9b2/0xb40 fs/reiserfs/xattr.c:311
reiserfs_delete_xattrs+0x1b/0x80 fs/reiserfs/xattr.c:364
reiserfs_evict_inode+0x20c/0x460 fs/reiserfs/inode.c:53
evict+0x2a4/0x620 fs/inode.c:666
d_delete_notify include/linux/fsnotify.h:267 [inline]
vfs_rmdir+0x381/0x4b0 fs/namei.c:4206
do_rmdir+0x3a2/0x590 fs/namei.c:4254
__do_sys_unlinkat fs/namei.c:4434 [inline]
__se_sys_unlinkat fs/namei.c:4428 [inline]
__x64_sys_unlinkat+0xdc/0xf0 fs/namei.c:4428
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x3b/0xb0 arch/x86/entry/common.c:81
entry_SYSCALL_64_after_hwframe+0x68/0xd2
RIP: 0033:0x7fb7d5978fd7
Code: 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 07 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc91c96e88 EFLAGS: 00000207 ORIG_RAX: 0000000000000107
RAX: ffffffffffffffda RBX: 0000000000000065 RCX: 00007fb7d5978fd7
RDX: 0000000000000200 RSI: 00007ffc91c98030 RDI: 00000000ffffff9c
RBP: 00007fb7d59e778c R08: 00005555571966ab R09: 0000000000000000
R10: 0000000000001000 R11: 0000000000000207 R12: 00007ffc91c98030
R13: 00007fb7d59e778c R14: 000000000002055b R15: 00007ffc91c9b2d0
</TASK>
REISERFS warning (device loop3): vs-13060 reiserfs_update_sd_size: stat data of object [1 2 0x0 SD] (nlink == 4) not found (pos 2)


---
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 report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

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

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