| Message ID | d16e7188-1afa-7513-990c-804811747bcb@linux.alibaba.com |
|---|---|
| State | New |
| Headers | show |
| Series | perf: fix panic by disable ftrace on fault.c | expand |
On 9/12/21 8:30 PM, 王贇 wrote: > According to the trace we know the story is like this, the NMI > triggered perf IRQ throttling and call perf_log_throttle(), > which triggered the swevent overflow, and the overflow process > do perf_callchain_user() which triggered a user PF, and the PF > process triggered perf ftrace which finally lead into a suspected > stack overflow. > > This patch disable ftrace on fault.c, which help to avoid the panic. ... > +# Disable ftrace to avoid stack overflow. > +CFLAGS_REMOVE_fault.o = $(CC_FLAGS_FTRACE) Was this observed on a mainline kernel? How reproducible is this? I suspect we're going into do_user_addr_fault(), then falling in here: > if (unlikely(faulthandler_disabled() || !mm)) { > bad_area_nosemaphore(regs, error_code, address); > return; > } Then something double faults in perf_swevent_get_recursion_context(). But, you snipped all of the register dump out so I can't quite see what's going on and what might have caused *that* fault. But, in my kernel perf_swevent_get_recursion_context+0x0/0x70 is: mov $0x27d00,%rdx which is rather unlikely to fault. Either way, we don't want to keep ftrace out of fault.c. This patch is just a hack, and doesn't really try to fix the underlying problem. This situation *should* be handled today. There's code there to handle it. Something else really funky is going on.
diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile index 5864219..1dbdca5 100644 --- a/arch/x86/mm/Makefile +++ b/arch/x86/mm/Makefile @@ -1,5 +1,9 @@ # SPDX-License-Identifier: GPL-2.0 # Kernel does not boot with instrumentation of tlb.c and mem_encrypt*.c + +# Disable ftrace to avoid stack overflow. +CFLAGS_REMOVE_fault.o = $(CC_FLAGS_FTRACE) + KCOV_INSTRUMENT_tlb.o := n KCOV_INSTRUMENT_mem_encrypt.o := n KCOV_INSTRUMENT_mem_encrypt_identity.o := n
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 According to the trace we know the story is like this, the NMI triggered perf IRQ throttling and call perf_log_throttle(), which triggered the swevent overflow, and the overflow process do perf_callchain_user() which triggered a user PF, and the PF process triggered perf ftrace which finally lead into a suspected stack overflow. This patch disable ftrace on fault.c, which help to avoid the panic. Reported-by: Abaci <abaci@linux.alibaba.com> Signed-off-by: Michael Wang <yun.wang@linux.alibaba.com> --- arch/x86/mm/Makefile | 4 ++++ 1 file changed, 4 insertions(+)