From: syzbot <syzbot+e5344baa319c9a96edec@syzkaller.appspotmail.com>
To: acme@kernel.org, alexander.shishkin@linux.intel.com,
jolsa@redhat.com, linux-kernel@vger.kernel.org,
mark.rutland@arm.com, mingo@redhat.com, namhyung@kernel.org,
peterz@infradead.org, syzkaller-bugs@googlegroups.com
Subject: possible deadlock in uprobe_clear_state (2)
Date: Wed, 15 Jul 2020 12:59:21 -0700 [thread overview]
Message-ID: <0000000000001fbbb605aa805c9b@google.com> (raw)
Hello,
syzbot found the following issue on:
HEAD commit: a581387e Merge tag 'io_uring-5.8-2020-07-10' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=111a004f100000
kernel config: https://syzkaller.appspot.com/x/.config?x=66ad203c2bb6d8b
dashboard link: https://syzkaller.appspot.com/bug?extid=e5344baa319c9a96edec
compiler: gcc (GCC) 10.1.0-syz 20200507
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+e5344baa319c9a96edec@syzkaller.appspotmail.com
======================================================
WARNING: possible circular locking dependency detected
5.8.0-rc4-syzkaller #0 Not tainted
------------------------------------------------------
syz-executor.1/4807 is trying to acquire lock:
ffffffff89c3a988 (delayed_uprobe_lock){+.+.}-{3:3}, at: uprobe_clear_state+0x47/0x3b0 kernel/events/uprobes.c:1550
but task is already holding lock:
ffffffff89c6c360 (fs_reclaim){+.+.}-{0:0}, at: fs_reclaim_release mm/page_alloc.c:4202 [inline]
ffffffff89c6c360 (fs_reclaim){+.+.}-{0:0}, at: fs_reclaim_release mm/page_alloc.c:4198 [inline]
ffffffff89c6c360 (fs_reclaim){+.+.}-{0:0}, at: __perform_reclaim mm/page_alloc.c:4227 [inline]
ffffffff89c6c360 (fs_reclaim){+.+.}-{0:0}, at: __alloc_pages_direct_reclaim mm/page_alloc.c:4244 [inline]
ffffffff89c6c360 (fs_reclaim){+.+.}-{0:0}, at: __alloc_pages_slowpath.constprop.0+0x1554/0x2780 mm/page_alloc.c:4650
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (fs_reclaim){+.+.}-{0:0}:
__fs_reclaim_acquire mm/page_alloc.c:4183 [inline]
fs_reclaim_acquire+0x2f/0x40 mm/page_alloc.c:4194
slab_pre_alloc_hook mm/slab.h:564 [inline]
slab_alloc mm/slab.c:3306 [inline]
kmem_cache_alloc_trace+0x29/0x2d0 mm/slab.c:3549
kmalloc include/linux/slab.h:555 [inline]
kzalloc include/linux/slab.h:669 [inline]
delayed_uprobe_add kernel/events/uprobes.c:304 [inline]
update_ref_ctr+0x4b6/0x700 kernel/events/uprobes.c:438
uprobe_write_opcode+0xe07/0x1650 kernel/events/uprobes.c:497
install_breakpoint kernel/events/uprobes.c:915 [inline]
install_breakpoint.isra.0+0x5a5/0x7c0 kernel/events/uprobes.c:897
uprobe_mmap+0x5d7/0x1050 kernel/events/uprobes.c:1394
mmap_region+0x5cf/0x1590 mm/mmap.c:1818
do_mmap+0xca8/0x1170 mm/mmap.c:1545
do_mmap_pgoff include/linux/mm.h:2596 [inline]
vm_mmap_pgoff+0x197/0x200 mm/util.c:506
ksys_mmap_pgoff+0x455/0x5a0 mm/mmap.c:1595
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
entry_SYSCALL_64_after_hwframe+0x44/0xa9
-> #0 (delayed_uprobe_lock){+.+.}-{3:3}:
check_prev_add kernel/locking/lockdep.c:2496 [inline]
check_prevs_add kernel/locking/lockdep.c:2601 [inline]
validate_chain kernel/locking/lockdep.c:3218 [inline]
__lock_acquire+0x2acb/0x56e0 kernel/locking/lockdep.c:4380
lock_acquire+0x1f1/0xad0 kernel/locking/lockdep.c:4959
__mutex_lock_common kernel/locking/mutex.c:956 [inline]
__mutex_lock+0x134/0x10d0 kernel/locking/mutex.c:1103
uprobe_clear_state+0x47/0x3b0 kernel/events/uprobes.c:1550
__mmput+0x73/0x470 kernel/fork.c:1089
mmput+0x53/0x60 kernel/fork.c:1114
binder_alloc_free_page+0x441/0xf90 drivers/android/binder_alloc.c:950
__list_lru_walk_one+0x178/0x5c0 mm/list_lru.c:222
list_lru_walk_one mm/list_lru.c:266 [inline]
list_lru_walk_node+0x67/0x2a0 mm/list_lru.c:295
list_lru_walk include/linux/list_lru.h:215 [inline]
binder_shrink_scan+0x123/0x190 drivers/android/binder_alloc.c:984
do_shrink_slab+0x3c6/0xab0 mm/vmscan.c:518
shrink_slab+0x16f/0x5c0 mm/vmscan.c:679
shrink_node_memcgs mm/vmscan.c:2658 [inline]
shrink_node+0x519/0x1b60 mm/vmscan.c:2770
shrink_zones mm/vmscan.c:2973 [inline]
do_try_to_free_pages+0x38b/0x1340 mm/vmscan.c:3026
try_to_free_pages+0x29a/0x8b0 mm/vmscan.c:3265
__perform_reclaim mm/page_alloc.c:4223 [inline]
__alloc_pages_direct_reclaim mm/page_alloc.c:4244 [inline]
__alloc_pages_slowpath.constprop.0+0x949/0x2780 mm/page_alloc.c:4650
__alloc_pages_nodemask+0x68f/0x930 mm/page_alloc.c:4863
alloc_pages_current+0x187/0x280 mm/mempolicy.c:2292
alloc_pages include/linux/gfp.h:545 [inline]
alloc_mmu_pages+0x7f/0x170 arch/x86/kvm/mmu/mmu.c:5671
kvm_mmu_create+0x3cb/0x560 arch/x86/kvm/mmu/mmu.c:5704
kvm_arch_vcpu_create+0x16d/0xb70 arch/x86/kvm/x86.c:9433
kvm_vm_ioctl_create_vcpu arch/x86/kvm/../../../virt/kvm/kvm_main.c:3060 [inline]
kvm_vm_ioctl+0x1547/0x23c0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3621
vfs_ioctl fs/ioctl.c:48 [inline]
ksys_ioctl+0x11a/0x180 fs/ioctl.c:753
__do_sys_ioctl fs/ioctl.c:762 [inline]
__se_sys_ioctl fs/ioctl.c:760 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
entry_SYSCALL_64_after_hwframe+0x44/0xa9
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(fs_reclaim);
lock(delayed_uprobe_lock);
lock(fs_reclaim);
lock(delayed_uprobe_lock);
*** DEADLOCK ***
3 locks held by syz-executor.1/4807:
#0: ffffffff89c6c360 (fs_reclaim){+.+.}-{0:0}, at: fs_reclaim_release mm/page_alloc.c:4202 [inline]
#0: ffffffff89c6c360 (fs_reclaim){+.+.}-{0:0}, at: fs_reclaim_release mm/page_alloc.c:4198 [inline]
#0: ffffffff89c6c360 (fs_reclaim){+.+.}-{0:0}, at: __perform_reclaim mm/page_alloc.c:4227 [inline]
#0: ffffffff89c6c360 (fs_reclaim){+.+.}-{0:0}, at: __alloc_pages_direct_reclaim mm/page_alloc.c:4244 [inline]
#0: ffffffff89c6c360 (fs_reclaim){+.+.}-{0:0}, at: __alloc_pages_slowpath.constprop.0+0x1554/0x2780 mm/page_alloc.c:4650
#1: ffffffff89c46b90 (shrinker_rwsem){++++}-{3:3}, at: shrink_slab+0xc7/0x5c0 mm/vmscan.c:669
#2: ffff88808ea481e0 (&alloc->mutex){+.+.}-{3:3}, at: binder_alloc_free_page+0x4f/0xf90 drivers/android/binder_alloc.c:923
stack backtrace:
CPU: 0 PID: 4807 Comm: syz-executor.1 Not tainted 5.8.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x18f/0x20d lib/dump_stack.c:118
check_noncircular+0x324/0x3e0 kernel/locking/lockdep.c:1827
check_prev_add kernel/locking/lockdep.c:2496 [inline]
check_prevs_add kernel/locking/lockdep.c:2601 [inline]
validate_chain kernel/locking/lockdep.c:3218 [inline]
__lock_acquire+0x2acb/0x56e0 kernel/locking/lockdep.c:4380
lock_acquire+0x1f1/0xad0 kernel/locking/lockdep.c:4959
__mutex_lock_common kernel/locking/mutex.c:956 [inline]
__mutex_lock+0x134/0x10d0 kernel/locking/mutex.c:1103
uprobe_clear_state+0x47/0x3b0 kernel/events/uprobes.c:1550
__mmput+0x73/0x470 kernel/fork.c:1089
mmput+0x53/0x60 kernel/fork.c:1114
binder_alloc_free_page+0x441/0xf90 drivers/android/binder_alloc.c:950
__list_lru_walk_one+0x178/0x5c0 mm/list_lru.c:222
list_lru_walk_one mm/list_lru.c:266 [inline]
list_lru_walk_node+0x67/0x2a0 mm/list_lru.c:295
list_lru_walk include/linux/list_lru.h:215 [inline]
binder_shrink_scan+0x123/0x190 drivers/android/binder_alloc.c:984
do_shrink_slab+0x3c6/0xab0 mm/vmscan.c:518
shrink_slab+0x16f/0x5c0 mm/vmscan.c:679
shrink_node_memcgs mm/vmscan.c:2658 [inline]
shrink_node+0x519/0x1b60 mm/vmscan.c:2770
shrink_zones mm/vmscan.c:2973 [inline]
do_try_to_free_pages+0x38b/0x1340 mm/vmscan.c:3026
try_to_free_pages+0x29a/0x8b0 mm/vmscan.c:3265
__perform_reclaim mm/page_alloc.c:4223 [inline]
__alloc_pages_direct_reclaim mm/page_alloc.c:4244 [inline]
__alloc_pages_slowpath.constprop.0+0x949/0x2780 mm/page_alloc.c:4650
__alloc_pages_nodemask+0x68f/0x930 mm/page_alloc.c:4863
alloc_pages_current+0x187/0x280 mm/mempolicy.c:2292
alloc_pages include/linux/gfp.h:545 [inline]
alloc_mmu_pages+0x7f/0x170 arch/x86/kvm/mmu/mmu.c:5671
kvm_mmu_create+0x3cb/0x560 arch/x86/kvm/mmu/mmu.c:5704
kvm_arch_vcpu_create+0x16d/0xb70 arch/x86/kvm/x86.c:9433
kvm_vm_ioctl_create_vcpu arch/x86/kvm/../../../virt/kvm/kvm_main.c:3060 [inline]
kvm_vm_ioctl+0x1547/0x23c0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3621
vfs_ioctl fs/ioctl.c:48 [inline]
ksys_ioctl+0x11a/0x180 fs/ioctl.c:753
__do_sys_ioctl fs/ioctl.c:762 [inline]
__se_sys_ioctl fs/ioctl.c:760 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45cba9
Code: Bad RIP value.
RSP: 002b:00007f45444f8c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000004e85c0 RCX: 000000000045cba9
RDX: 0000000000000000 RSI: 000000000000ae41 RDI: 0000000000000004
RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000000003a3 R14: 00000000004c652f R15: 00007f45444f96d4
---
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 syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
next reply other threads:[~2020-07-15 19:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-15 19:59 syzbot [this message]
2020-07-15 23:36 ` [PATCH] binder: Don't use mmput() from shrinker function Tetsuo Handa
2020-07-16 8:35 ` Michal Hocko
2020-07-16 13:41 ` Tetsuo Handa
2020-07-16 13:54 ` Michal Hocko
2020-07-16 15:12 ` [PATCH v2] " Tetsuo Handa
2020-07-16 15:17 ` Michal Hocko
2020-07-16 16:29 ` Christian Brauner
2020-07-16 22:27 ` Tetsuo Handa
2020-07-16 23:53 ` Todd Kjos
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=0000000000001fbbb605aa805c9b@google.com \
--to=syzbot+e5344baa319c9a96edec@syzkaller.appspotmail.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.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.