[syzbot] WARNING in perf_pending_event

8 views
Skip to first unread message

syzbot

unread,
Nov 9, 2021, 7:17:21 AM11/9/21
to ac...@kernel.org, alexander...@linux.intel.com, and...@kernel.org, a...@kernel.org, b...@vger.kernel.org, dan...@iogearbox.net, john.fa...@gmail.com, jo...@redhat.com, ka...@fb.com, kps...@kernel.org, linux-...@vger.kernel.org, linux-pe...@vger.kernel.org, mark.r...@arm.com, mi...@redhat.com, namh...@kernel.org, net...@vger.kernel.org, pet...@infradead.org, songliu...@fb.com, syzkall...@googlegroups.com, y...@fb.com
Hello,

syzbot found the following issue on:

HEAD commit: 85a90500f9a1 Merge tag 'io_uring-5.14-2021-08-07' of git:/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13c8aa81300000
kernel config: https://syzkaller.appspot.com/x/.config?x=5ba4a97de189f896
dashboard link: https://syzkaller.appspot.com/bug?extid=23843634c323e144fd0b
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12ac8392300000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1039bce6300000

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

------------[ cut here ]------------
WARNING: CPU: 0 PID: 8449 at kernel/events/core.c:6407 perf_sigtrap kernel/events/core.c:6407 [inline]
WARNING: CPU: 0 PID: 8449 at kernel/events/core.c:6407 perf_pending_event_disable kernel/events/core.c:6431 [inline]
WARNING: CPU: 0 PID: 8449 at kernel/events/core.c:6407 perf_pending_event+0x4ba/0x560 kernel/events/core.c:6474
Modules linked in:
CPU: 0 PID: 8449 Comm: syz-executor996 Not tainted 5.14.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:perf_sigtrap kernel/events/core.c:6407 [inline]
RIP: 0010:perf_pending_event_disable kernel/events/core.c:6431 [inline]
RIP: 0010:perf_pending_event+0x4ba/0x560 kernel/events/core.c:6474
Code: ff 4c 89 e7 e8 d7 78 27 00 e9 2f ff ff ff e8 ad 78 27 00 e9 3d fc ff ff 4c 89 ff e8 30 79 27 00 e9 fb fb ff ff e8 b6 ba e1 ff <0f> 0b e9 86 fd ff ff e8 ba 78 27 00 e9 7b fe ff ff 48 89 df e8 9d
RSP: 0018:ffffc90000007f38 EFLAGS: 00010046
RAX: 0000000080010001 RBX: ffff88802a04fc40 RCX: 0000000000000000
RDX: ffff8880377e0040 RSI: ffffffff8193268a RDI: ffff888026467958
RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000020
R10: ffffffff819322cb R11: 0000000000000000 R12: ffff8880377e0040
R13: ffff888026467800 R14: ffff88802a04f800 R15: ffff88802a04fc30
FS: 0000000000545300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004d05c0 CR3: 000000003d54f000 CR4: 00000000001506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<IRQ>
irq_work_single+0x120/0x1f0 kernel/irq_work.c:155
irq_work_run_list+0x91/0xc0 kernel/irq_work.c:177
irq_work_run+0x54/0xd0 kernel/irq_work.c:186
__sysvec_irq_work+0x95/0x3d0 arch/x86/kernel/irq_work.c:22
sysvec_irq_work+0x8e/0xc0 arch/x86/kernel/irq_work.c:17
</IRQ>
asm_sysvec_irq_work+0x12/0x20 arch/x86/include/asm/idtentry.h:664
RIP: 0010:__raw_spin_unlock_irq include/linux/spinlock_api_smp.h:169 [inline]
RIP: 0010:_raw_spin_unlock_irq+0x25/0x40 kernel/locking/spinlock.c:199
Code: 0f 1f 44 00 00 55 48 8b 74 24 08 48 89 fd 48 83 c7 18 e8 3e 1a 2d f8 48 89 ef e8 e6 8f 2d f8 e8 21 cb 4d f8 fb bf 01 00 00 00 <e8> 36 6a 21 f8 65 8b 05 cf b0 d4 76 85 c0 74 02 5d c3 e8 2b 06 d3
RSP: 0018:ffffc90001a17ee8 EFLAGS: 00000202
RAX: 0000000000000315 RBX: 0000000000000000 RCX: 1ffffffff1ad8461
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
RBP: ffff888021b9cb40 R08: 0000000000000001 R09: 0000000000000001
R10: ffffffff817b0a38 R11: 0000000000000000 R12: ffff888033f2f320
R13: 0000000000000000 R14: ffff888021b9cb40 R15: ffff8880377e0040
spin_unlock_irq include/linux/spinlock.h:404 [inline]
do_group_exit+0x29a/0x310 kernel/exit.c:919
__do_sys_exit_group kernel/exit.c:933 [inline]
__se_sys_exit_group kernel/exit.c:931 [inline]
__x64_sys_exit_group+0x3a/0x50 kernel/exit.c:931
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x444379
Code: 00 49 c7 c0 b8 ff ff ff be e7 00 00 00 ba 3c 00 00 00 eb 12 0f 1f 44 00 00 89 d0 0f 05 48 3d 00 f0 ff ff 77 1c f4 89 f0 0f 05 <48> 3d 00 f0 ff ff 76 e7 f7 d8 64 41 89 00 eb df 0f 1f 80 00 00 00
RSP: 002b:00007fffad23f4c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 00000000004ca370 RCX: 0000000000444379
RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000
RBP: 0000000000000000 R08: ffffffffffffffb8 R09: 0000000000f0b5ff
R10: 00007fffad23f550 R11: 0000000000000246 R12: 00000000004ca370
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001


---
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 syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

Marco Elver

unread,
Nov 9, 2021, 7:22:40 AM11/9/21
to pet...@infradead.org, mi...@redhat.com, mark.r...@arm.com, namh...@kernel.org, ac...@kernel.org, alexander...@linux.intel.com, jo...@redhat.com, syzbot, and...@kernel.org, a...@kernel.org, b...@vger.kernel.org, dan...@iogearbox.net, john.fa...@gmail.com, ka...@fb.com, kps...@kernel.org, linux-...@vger.kernel.org, linux-pe...@vger.kernel.org, net...@vger.kernel.org, songliu...@fb.com, syzkall...@googlegroups.com, y...@fb.com
syzbot reported that the warning in perf_sigtrap() fires, saying that
the event's task does not match current:

| WARNING: CPU: 0 PID: 9090 at kernel/events/core.c:6446 perf_pending_event+0x40d/0x4b0 kernel/events/core.c:6513
| Modules linked in:
| CPU: 0 PID: 9090 Comm: syz-executor.1 Not tainted 5.15.0-syzkaller #0
| Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
| RIP: 0010:perf_sigtrap kernel/events/core.c:6446 [inline]
| RIP: 0010:perf_pending_event_disable kernel/events/core.c:6470 [inline]
| RIP: 0010:perf_pending_event+0x40d/0x4b0 kernel/events/core.c:6513
| ...
| Call Trace:
| <IRQ>
| irq_work_single+0x106/0x220 kernel/irq_work.c:211
| irq_work_run_list+0x6a/0x90 kernel/irq_work.c:242
| irq_work_run+0x4f/0xd0 kernel/irq_work.c:251
| __sysvec_irq_work+0x95/0x3d0 arch/x86/kernel/irq_work.c:22
| sysvec_irq_work+0x8e/0xc0 arch/x86/kernel/irq_work.c:17
| </IRQ>
| <TASK>
| asm_sysvec_irq_work+0x12/0x20 arch/x86/include/asm/idtentry.h:664
| RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline]
| RIP: 0010:_raw_spin_unlock_irqrestore+0x38/0x70 kernel/locking/spinlock.c:194
| ...
| coredump_task_exit kernel/exit.c:371 [inline]
| do_exit+0x1865/0x25c0 kernel/exit.c:771
| do_group_exit+0xe7/0x290 kernel/exit.c:929
| get_signal+0x3b0/0x1ce0 kernel/signal.c:2820
| arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:868
| handle_signal_work kernel/entry/common.c:148 [inline]
| exit_to_user_mode_loop kernel/entry/common.c:172 [inline]
| exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:207
| __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]
| syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300
| do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
| entry_SYSCALL_64_after_hwframe+0x44/0xae

On x86 this shouldn't happen, which has arch_irq_work_raise().

The test program sets up a perf event with sigtrap set to fire on the
'sched_wakeup' tracepoint, which fired in ttwu_do_wakeup().

This happened because the 'sched_wakeup' tracepoint also takes a task
argument passed on to perf_tp_event(), which is used to deliver the
event to that other task.

Since we cannot deliver synchronous signals to other tasks, skip an event if
perf_tp_event() is targeted at another task and perf_event_attr::sigtrap is
set, which will avoid ever entering perf_sigtrap() for such events.

Fixes: 97ba62b27867 ("perf: Add support for SIGTRAP on perf events")
Reported-by: syzbot+663359...@syzkaller.appspotmail.com
Signed-off-by: Marco Elver <el...@google.com>
---
kernel/events/core.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index f23ca260307f..91653c6e41a7 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -9729,6 +9729,9 @@ void perf_tp_event(u16 event_type, u64 count, void *record, int entry_size,
continue;
if (event->attr.config != entry->type)
continue;
+ /* Cannot deliver synchronous signal to other task. */
+ if (event->attr.sigtrap)
+ continue;
if (perf_tp_event_match(event, &data, regs))
perf_swevent_event(event, count, &data, regs);
}
--
2.34.0.rc0.344.g81b53c2807-goog

Marco Elver

unread,
Nov 17, 2021, 9:07:20 AM11/17/21
to pet...@infradead.org, mi...@redhat.com, mark.r...@arm.com, namh...@kernel.org, ac...@kernel.org, alexander...@linux.intel.com, jo...@redhat.com, syzbot, and...@kernel.org, a...@kernel.org, b...@vger.kernel.org, dan...@iogearbox.net, john.fa...@gmail.com, ka...@fb.com, kps...@kernel.org, linux-...@vger.kernel.org, linux-pe...@vger.kernel.org, net...@vger.kernel.org, songliu...@fb.com, syzkall...@googlegroups.com, y...@fb.com
On Tue, 9 Nov 2021 at 13:22, Marco Elver <el...@google.com> wrote:
> syzbot reported that the warning in perf_sigtrap() fires, saying that
> the event's task does not match current:
>
> | WARNING: CPU: 0 PID: 9090 at kernel/events/core.c:6446 perf_pending_event+0x40d/0x4b0 kernel/events/core.c:6513
[...]
> This happened because the 'sched_wakeup' tracepoint also takes a task
> argument passed on to perf_tp_event(), which is used to deliver the
> event to that other task.
>
> Since we cannot deliver synchronous signals to other tasks, skip an event if
> perf_tp_event() is targeted at another task and perf_event_attr::sigtrap is
> set, which will avoid ever entering perf_sigtrap() for such events.
[...]

Hmm, I made the mistake of sending this in the merge-window.
Any comments?

Thanks,
-- Marco
Reply all
Reply to author
Forward
0 new messages