possible deadlock in perf_swevent_init

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit: 4a739e35 Merge 4.14.101 into android-4.14
git tree: android-4.14
console output: https://syzkaller.appspot.com/x/log.txt?x=11573da8c00000
kernel config: https://syzkaller.appspot.com/x/.config?x=fa88ec8e8cdb00c8
dashboard link: https://syzkaller.appspot.com/bug?extid=2c32a3f0943cce092de8
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11931360c00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=166b2414c00000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2c32a3...@syzkaller.appspotmail.com

random: sshd: uninitialized urandom read (32 bytes read)
audit: type=1400 audit(1550407535.411:7): avc: denied { map } for
pid=1784 comm="syz-executor813" path="/root/syz-executor813874553"
dev="sda1" ino=16482 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
audit: type=1400 audit(1550407535.461:8): avc: denied { create } for
pid=1784 comm="syz-executor813"
scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tclass=netlink_iscsi_socket permissive=1
======================================================
WARNING: possible circular locking dependency detected
4.14.101+ #14 Not tainted
------------------------------------------------------
syz-executor813/1784 is trying to acquire lock:
(pmus_lock){+.+.}, at: [<ffffffff9e9e5793>] swevent_hlist_get
kernel/events/core.c:7886 [inline]
(pmus_lock){+.+.}, at: [<ffffffff9e9e5793>] perf_swevent_init+0x123/0x4e0
kernel/events/core.c:7946

but task is already holding lock:
(&cpuctx_mutex/1){+.+.}, at: [<ffffffff9e9e8b2d>]
perf_event_ctx_lock_nested+0x14d/0x2c0 kernel/events/core.c:1240

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (&cpuctx_mutex/1){+.+.}:

-> #1 (&cpuctx_mutex){+.+.}:

-> #0 (pmus_lock){+.+.}:

other info that might help us debug this:

Chain exists of:
pmus_lock --> &cpuctx_mutex --> &cpuctx_mutex/1

Possible unsafe locking scenario:

CPU0 CPU1
---- ----
lock(&cpuctx_mutex/1);
lock(&cpuctx_mutex);
lock(&cpuctx_mutex/1);
lock(pmus_lock);

*** DEADLOCK ***

2 locks held by syz-executor813/1784:
#0: (&pmus_srcu){....}, at: [<ffffffff9e9f123d>]
perf_event_alloc.part.0+0xadd/0x1e70 kernel/events/core.c:9621
#1: (&cpuctx_mutex/1){+.+.}, at: [<ffffffff9e9e8b2d>]
perf_event_ctx_lock_nested+0x14d/0x2c0 kernel/events/core.c:1240

stack backtrace:
CPU: 0 PID: 1784 Comm: syz-executor813 Not tainted 4.14.101+ #14
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0xb9/0x10e lib/dump_stack.c:53
print_circular_bug.isra.0.cold+0x2dc/0x425 kernel/locking/lockdep.c:1258


---
This bug 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 bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches