From: syzbot <syzbot+ff866d16791d4984b3c7@syzkaller.appspotmail.com>
To: linux-kernel@vger.kernel.org, reiserfs-devel@vger.kernel.org,
syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [reiserfs?] possible deadlock in do_page_mkwrite
Date: Fri, 23 Dec 2022 02:50:40 -0800 [thread overview]
Message-ID: <0000000000007c321405f07c8e00@google.com> (raw)
In-Reply-To: <00000000000032654605ef9c1846@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: 8395ae05cb5a Merge tag 'scsi-misc' of git://git.kernel.org..
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=14e189f8480000
kernel config: https://syzkaller.appspot.com/x/.config?x=4e2d7bfa2d6d5a76
dashboard link: https://syzkaller.appspot.com/bug?extid=ff866d16791d4984b3c7
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=1282218c480000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=148aa0a8480000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/801dbf77dd1d/disk-8395ae05.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2a057f4aa500/vmlinux-8395ae05.xz
kernel image: https://storage.googleapis.com/syzbot-assets/70a630e3d523/bzImage-8395ae05.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/1b64a5dd0f67/mount_0.gz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ff866d16791d4984b3c7@syzkaller.appspotmail.com
WARNING: possible circular locking dependency detected
6.1.0-syzkaller-14446-g8395ae05cb5a #0 Not tainted
------------------------------------------------------
syz-executor409/5148 is trying to acquire lock:
ffff888017eac090 (&sbi->lock){+.+.}-{3:3}, at: reiserfs_write_lock+0x77/0xd0 fs/reiserfs/lock.c:27
but task is already holding lock:
ffff88802081e558 (sb_pagefaults){.+.+}-{0:0}, at: do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (sb_pagefaults){.+.+}-{0:0}:
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:1811 [inline]
sb_start_pagefault include/linux/fs.h:1915 [inline]
filemap_page_mkwrite+0x15c/0x7a0 mm/filemap.c:3439
do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947
wp_page_shared+0x15e/0x380 mm/memory.c:3295
handle_pte_fault mm/memory.c:4949 [inline]
__handle_mm_fault mm/memory.c:5073 [inline]
handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219
do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428
handle_page_fault arch/x86/mm/fault.c:1519 [inline]
exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575
asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570
-> #1 (&mm->mmap_lock){++++}-{3:3}:
lock_acquire+0x182/0x3c0 kernel/locking/lockdep.c:5668
__might_fault+0xb2/0x110 mm/memory.c:5647
reiserfs_ioctl+0x11c/0x340 fs/reiserfs/ioctl.c:96
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
-> #0 (&sbi->lock){+.+.}-{3:3}:
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
__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_dirty_inode+0xdf/0x230 fs/reiserfs/super.c:704
__mark_inode_dirty+0x1e7/0x600 fs/fs-writeback.c:2419
generic_update_time fs/inode.c:1859 [inline]
inode_update_time fs/inode.c:1872 [inline]
__file_update_time fs/inode.c:2057 [inline]
file_update_time+0x551/0x5d0 fs/inode.c:2088
filemap_page_mkwrite+0x248/0x7a0 mm/filemap.c:3440
do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947
wp_page_shared+0x15e/0x380 mm/memory.c:3295
handle_pte_fault mm/memory.c:4949 [inline]
__handle_mm_fault mm/memory.c:5073 [inline]
handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219
do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428
handle_page_fault arch/x86/mm/fault.c:1519 [inline]
exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575
asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570
other info that might help us debug this:
Chain exists of:
&sbi->lock --> &mm->mmap_lock --> sb_pagefaults
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(sb_pagefaults);
lock(&mm->mmap_lock);
lock(sb_pagefaults);
lock(&sbi->lock);
*** DEADLOCK ***
2 locks held by syz-executor409/5148:
#0: ffff88801d47c758 (&mm->mmap_lock){++++}-{3:3}, at: mmap_read_trylock include/linux/mmap_lock.h:136 [inline]
#0: ffff88801d47c758 (&mm->mmap_lock){++++}-{3:3}, at: do_user_addr_fault+0x2e2/0xcb0 arch/x86/mm/fault.c:1369
#1: ffff88802081e558 (sb_pagefaults){.+.+}-{0:0}, at: do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947
stack backtrace:
CPU: 0 PID: 5148 Comm: syz-executor409 Not tainted 6.1.0-syzkaller-14446-g8395ae05cb5a #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/0x290 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
__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_dirty_inode+0xdf/0x230 fs/reiserfs/super.c:704
__mark_inode_dirty+0x1e7/0x600 fs/fs-writeback.c:2419
generic_update_time fs/inode.c:1859 [inline]
inode_update_time fs/inode.c:1872 [inline]
__file_update_time fs/inode.c:2057 [inline]
file_update_time+0x551/0x5d0 fs/inode.c:2088
filemap_page_mkwrite+0x248/0x7a0 mm/filemap.c:3440
do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947
wp_page_shared+0x15e/0x380 mm/memory.c:3295
handle_pte_fault mm/memory.c:4949 [inline]
__handle_mm_fault mm/memory.c:5073 [inline]
handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219
do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428
handle_page_fault arch/x86/mm/fault.c:1519 [inline]
exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575
asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570
RIP: 0033:0x7f61a34e95a0
Code: 00 e8 14 26 04 00 48 8b 35 bd 5b 0b 00 31 c9 31 c0 ba 01 76 08 80 bf 10 00 00 00 e8 fa 25 04 00 b8 98 00 00 20 b9 20 00 00 00 <c7> 04 25 80 00 00 20 08 00 00 00 66 c7 04 25 84 00 00 20 20 01 48
RSP: 002b:00007ffd03dae660 EFLAGS: 00010286
RAX: 0000000020000098 RBX: 000000000000f4c9 RCX: 0000000000000020
RDX: 0000000000000000 RSI: 0000000080087601 RDI: 0000000000000004
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd03dae68c
R13: 00007ffd03dae6c0 R14: 00007ffd03dae6a0 R15: 0000000000000006
</TASK>
next prev parent reply other threads:[~2022-12-23 10:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-12 7:03 [syzbot] possible deadlock in do_page_mkwrite syzbot
2022-12-23 10:50 ` syzbot [this message]
2024-03-09 0:24 ` [syzbot] [reiserfs?] " syzbot
[not found] <20221223112733.2065-1-hdanton@sina.com>
2022-12-23 20:14 ` 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=0000000000007c321405f07c8e00@google.com \
--to=syzbot+ff866d16791d4984b3c7@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.