On Thu, Mar 25, 2021 at 05:17PM +0100, Marco Elver wrote: [...]
syzkaller found a crash with stack trace pointing at changes in this patch. Can't tell if this is an old issue or introduced in this series.
Yay, I found a reproducer. v5.12-rc4 is good, and sadly with this patch only we crash. :-/
Here's a stacktrace with just this patch applied:
| BUG: kernel NULL pointer dereference, address: 00000000000007af
[...]
| RIP: 0010:task_pid_ptr kernel/pid.c:324 [inline] | RIP: 0010:__task_pid_nr_ns+0x112/0x240 kernel/pid.c:500
[...]
| Call Trace: | perf_event_pid_type kernel/events/core.c:1412 [inline] | perf_event_pid kernel/events/core.c:1421 [inline] | perf_event_read_event+0x78/0x1d0 kernel/events/core.c:7406 | sync_child_event kernel/events/core.c:12404 [inline] | perf_child_detach kernel/events/core.c:2223 [inline] | __perf_remove_from_context+0x14d/0x280 kernel/events/core.c:2359 | perf_remove_from_context+0x9f/0xf0 kernel/events/core.c:2395 | perf_event_exit_event kernel/events/core.c:12442 [inline] | perf_event_exit_task_context kernel/events/core.c:12523 [inline] | perf_event_exit_task+0x276/0x4c0 kernel/events/core.c:12556 | do_exit+0x4cd/0xed0 kernel/exit.c:834 | do_group_exit+0x4d/0xf0 kernel/exit.c:922 | get_signal+0x1d2/0xf30 kernel/signal.c:2777 | arch_do_signal_or_restart+0xf7/0x750 arch/x86/kernel/signal.c:789 | handle_signal_work kernel/entry/common.c:147 [inline] | exit_to_user_mode_loop kernel/entry/common.c:171 [inline] | exit_to_user_mode_prepare+0x113/0x190 kernel/entry/common.c:208 | irqentry_exit_to_user_mode+0x6/0x30 kernel/entry/common.c:314 | asm_exc_general_protection+0x1e/0x30 arch/x86/include/asm/idtentry.h:571
I spun up gdb, and it showed me this:
| #0 perf_event_read_event (event=event@entry=0xffff888107cd5000, task=task@entry=0xffffffffffffffff) | at kernel/events/core.c:7397 ^^^ TASK_TOMBSTONE | #1 0xffffffff811fc9cd in sync_child_event (child_event=0xffff888107cd5000) at kernel/events/core.c:12404 | #2 perf_child_detach (event=0xffff888107cd5000) at kernel/events/core.c:2223 | #3 __perf_remove_from_context (event=event@entry=0xffff888107cd5000, cpuctx=cpuctx@entry=0xffff88842fdf0c00, | ctx=ctx@entry=0xffff8881073cb800, info=info@entry=0x3 <fixed_percpu_data+3>) at kernel/events/core.c:2359 | #4 0xffffffff811fcb9f in perf_remove_from_context (event=event@entry=0xffff888107cd5000, flags=flags@entry=3) | at kernel/events/core.c:2395 | #5 0xffffffff81204526 in perf_event_exit_event (ctx=0xffff8881073cb800, event=0xffff888107cd5000) | at kernel/events/core.c:12442 | #6 perf_event_exit_task_context (ctxn=0, child=0xffff88810531a200) at kernel/events/core.c:12523 | #7 perf_event_exit_task (child=0xffff88810531a200) at kernel/events/core.c:12556 | #8 0xffffffff8108838d in do_exit (code=code@entry=11) at kernel/exit.c:834 | #9 0xffffffff81088e4d in do_group_exit (exit_code=11) at kernel/exit.c:922
and therefore synthesized this fix on top:
diff --git a/kernel/events/core.c b/kernel/events/core.c index 57de8d436efd..e77294c7e654 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -12400,7 +12400,7 @@ static void sync_child_event(struct perf_event *child_event) if (child_event->attr.inherit_stat) { struct task_struct *task = child_event->ctx->task;
- if (task) + if (task && task != TASK_TOMBSTONE) perf_event_read_event(child_event, task); }
which fixes the problem. My guess is that the parent and child are both racing to exit?
Does that make any sense?
Thanks, -- Marco