Re: [PATCH] perf: fix panic by disable ftrace on fault.c

On 2021/9/13 下午10:49, Dave Hansen wrote:

On 9/12/21 8:30 PM, 王贇 wrote:

quoted

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.

...

quoted

+# Disable ftrace to avoid stack overflow.
+CFLAGS_REMOVE_fault.o = $(CC_FLAGS_FTRACE)

Was this observed on a mainline kernel?

Yes, it is trigger on linux-next.

How reproducible is this?

I suspect we're going into do_user_addr_fault(), then falling in here:

quoted

        if (unlikely(faulthandler_disabled() || !mm)) {
                bad_area_nosemaphore(regs, error_code, address);
                return;
        }

Correct, perf_callchain_user() disabled PF which lead into here.

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.

Would you like to check the full trace I just sent see if we can get any
clue?

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.

Do you think stack overflow is possible in this case? To be mentioned the NMI
arrive in very high frequency, and reduce perf_event_max_sample_rate to a low
value can also avoid the panic.

Regards,
Michael Wang