From: syzbot <syzbot+c473aa669b5e8a6f48d2@syzkaller.appspotmail.com>
To: eadavis@qq.com, linux-kernel@vger.kernel.org,
syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [mm?] possible deadlock in mfill_get_vma
Date: Sun, 15 Mar 2026 18:35:05 -0700 [thread overview]
Message-ID: <69b75e49.050a0220.248e02.0106.GAE@google.com> (raw)
In-Reply-To: <tencent_6E2B4FC70DF525AF8DBD124BDDEB5DEA9907@qq.com>
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
possible deadlock in lock_vma_under_rcu
======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
syz.0.17/6543 is trying to acquire lock:
ffff8880342d8338 (&mm->mmap_lock){++++}-{4:4}, at: __might_fault+0xaf/0x130 mm/memory.c:7249
but task is already holding lock:
ffff88802c19fbc8 (vm_lock){++++}-{0:0}, at: lock_vma_under_rcu+0x1d1/0x500 mm/mmap_lock.c:310
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (vm_lock){++++}-{0:0}:
__vma_start_exclude_readers+0x28a/0x940 mm/mmap_lock.c:125
__vma_start_write+0xdc/0x290 mm/mmap_lock.c:148
vma_start_write include/linux/mmap_lock.h:303 [inline]
mprotect_fixup+0x5eb/0xa80 mm/mprotect.c:768
setup_arg_pages+0x565/0xac0 fs/exec.c:670
load_elf_binary+0xc5e/0x2980 fs/binfmt_elf.c:1029
search_binary_handler fs/exec.c:1664 [inline]
exec_binprm fs/exec.c:1696 [inline]
bprm_execve+0x949/0x1470 fs/exec.c:1748
kernel_execve+0x844/0x930 fs/exec.c:1892
try_to_run_init_process+0x13/0x60 init/main.c:1514
kernel_init+0xad/0x1d0 init/main.c:1642
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #0 (&mm->mmap_lock){++++}-{4:4}:
check_prev_add kernel/locking/lockdep.c:3165 [inline]
check_prevs_add kernel/locking/lockdep.c:3284 [inline]
validate_chain kernel/locking/lockdep.c:3908 [inline]
__lock_acquire+0x15a5/0x2cf0 kernel/locking/lockdep.c:5237
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
__might_fault+0xcb/0x130 mm/memory.c:7249
userfaultfd_continue fs/userfaultfd.c:1813 [inline]
userfaultfd_ioctl+0x2372/0x4c70 fs/userfaultfd.c:2071
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
rlock(vm_lock);
lock(&mm->mmap_lock);
lock(vm_lock);
rlock(&mm->mmap_lock);
*** DEADLOCK ***
1 lock held by syz.0.17/6543:
#0: ffff88802c19fbc8 (vm_lock){++++}-{0:0}, at: lock_vma_under_rcu+0x1d1/0x500 mm/mmap_lock.c:310
stack backtrace:
CPU: 0 UID: 0 PID: 6543 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_circular_bug+0x2e1/0x300 kernel/locking/lockdep.c:2043
check_noncircular+0x12e/0x150 kernel/locking/lockdep.c:2175
check_prev_add kernel/locking/lockdep.c:3165 [inline]
check_prevs_add kernel/locking/lockdep.c:3284 [inline]
validate_chain kernel/locking/lockdep.c:3908 [inline]
__lock_acquire+0x15a5/0x2cf0 kernel/locking/lockdep.c:5237
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
__might_fault+0xcb/0x130 mm/memory.c:7249
userfaultfd_continue fs/userfaultfd.c:1813 [inline]
userfaultfd_ioctl+0x2372/0x4c70 fs/userfaultfd.c:2071
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fab1159c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fab12535028 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007fab11815fa0 RCX: 00007fab1159c799
RDX: 0000200000000080 RSI: 00000000c020aa07 RDI: 0000000000000003
RBP: 00007fab11632c99 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fab11816038 R14: 00007fab11815fa0 R15: 00007ffcb27f4f28
</TASK>
Tested on:
commit: b84a0ebe Add linux-next specific files for 20260313
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=148f44da580000
kernel config: https://syzkaller.appspot.com/x/.config?x=e7280ad1f68b2dce
dashboard link: https://syzkaller.appspot.com/bug?extid=c473aa669b5e8a6f48d2
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch: https://syzkaller.appspot.com/x/patch.diff?x=130228da580000
next prev parent reply other threads:[~2026-03-16 1:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-15 18:37 [syzbot] [mm?] possible deadlock in mfill_get_vma syzbot
2026-03-16 0:57 ` Edward Adam Davis
2026-03-16 1:35 ` syzbot [this message]
2026-03-16 1:19 ` Hillf Danton
2026-03-16 1:56 ` syzbot
2026-03-16 1:49 ` Edward Adam Davis
2026-03-16 2:20 ` syzbot
2026-03-16 2:21 ` Edward Adam Davis
2026-03-16 3:07 ` syzbot
2026-03-16 3:11 ` [PATCH next] userfaultfd: unassigned vma leads to a potential unreleased locks Edward Adam Davis
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=69b75e49.050a0220.248e02.0106.GAE@google.com \
--to=syzbot+c473aa669b5e8a6f48d2@syzkaller.appspotmail.com \
--cc=eadavis@qq.com \
--cc=linux-kernel@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.