[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7aa8133d-a9e4-f0ae-7c98-4a38f0ca25d9@linux.alibaba.com>
Date: Mon, 13 Sep 2021 11:21:30 +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/13 上午11:00, 王贇 wrote:
>
>
> 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...
By a second thinking, I think you're right about the
way it should be fixed, since disabling ftrace on
'arch/x86/mm/fault.c' could also fix the problem.
Will send a formal patch later :-)
Regards,
Michael Wang
>
> Regards,
> Michael Wang
>
>>
Powered by blists - more mailing lists