All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.