[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f38987a5-dc36-a20d-8c5e-81e8ead5b4dc@linux.alibaba.com>
Date: Mon, 13 Sep 2021 11:00:47 +0800
From: 王贇 <yun.wang@...ux.alibaba.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>,
"open list:PERFORMANCE EVENTS SUBSYSTEM"
<linux-perf-users@...r.kernel.org>,
"open list:PERFORMANCE EVENTS SUBSYSTEM"
<linux-kernel@...r.kernel.org>,
"open list:BPF (Safe dynamic programs and tools)"
<netdev@...r.kernel.org>,
"open list:BPF (Safe dynamic programs and tools)"
<bpf@...r.kernel.org>
Subject: Re: [RFC PATCH] perf: fix panic by mark recursion inside
perf_log_throttle
On 2021/9/10 下午11:38, Peter Zijlstra wrote:
> On Thu, Sep 09, 2021 at 11:13:21AM +0800, 王贇 wrote:
>> When running with ftrace function enabled, we observed panic
>> as below:
>>
>> traps: PANIC: double fault, error_code: 0x0
>> [snip]
>> RIP: 0010:perf_swevent_get_recursion_context+0x0/0x70
>> [snip]
>> Call Trace:
>> <NMI>
>> perf_trace_buf_alloc+0x26/0xd0
>> perf_ftrace_function_call+0x18f/0x2e0
>> kernelmode_fixup_or_oops+0x5/0x120
>> __bad_area_nosemaphore+0x1b8/0x280
>> do_user_addr_fault+0x410/0x920
>> exc_page_fault+0x92/0x300
>> asm_exc_page_fault+0x1e/0x30
>> RIP: 0010:__get_user_nocheck_8+0x6/0x13
>> perf_callchain_user+0x266/0x2f0
>> get_perf_callchain+0x194/0x210
>> perf_callchain+0xa3/0xc0
>> perf_prepare_sample+0xa5/0xa60
>> perf_event_output_forward+0x7b/0x1b0
>> __perf_event_overflow+0x67/0x120
>> perf_swevent_overflow+0xcb/0x110
>> perf_swevent_event+0xb0/0xf0
>> perf_tp_event+0x292/0x410
>> perf_trace_run_bpf_submit+0x87/0xc0
>> perf_trace_lock_acquire+0x12b/0x170
>> lock_acquire+0x1bf/0x2e0
>> perf_output_begin+0x70/0x4b0
>> perf_log_throttle+0xe2/0x1a0
>> perf_event_nmi_handler+0x30/0x50
>> nmi_handle+0xba/0x2a0
>> default_do_nmi+0x45/0xf0
>> exc_nmi+0x155/0x170
>> end_repeat_nmi+0x16/0x55
>
> kernel/events/Makefile has:
>
> ifdef CONFIG_FUNCTION_TRACER
> CFLAGS_REMOVE_core.o = $(CC_FLAGS_FTRACE)
> endif
>
> Which, afaict, should avoid the above, no?
I'm afraid it's not working for this case, the
start point of tracing is at lock_acquire() which
is not from 'kernel/events/core', the following PF
related function are also not from 'core', prevent
ftrace on 'core' can't prevent this from happen...
Regards,
Michael Wang
>
Powered by blists - more mailing lists