When update the latest mainline kernel with the following three configs,
the kernel hangs during startup:
(1) CONFIG_FUNCTION_GRAPH_TRACER=y
(2) CONFIG_PREEMPT_TRACER=y
(3) CONFIG_FTRACE_STARTUP_TEST=y
When update the latest mainline kernel with the above two configs (1)
and (2), the kernel starts normally, but it still hangs when execute
the following command:
echo "function_graph" > /sys/kernel/debug/tracing/current_tracer
Without CONFIG_PREEMPT_TRACER=y, the above two kinds of kernel hangs
disappeared, so it seems that CONFIG_PREEMPT_TRACER has some influences
with function_graph tracer at the first glance.
I use ejtag to find out the epc address is related with preempt_enable()
in the file arch/mips/lib/mips-atomic.c, because function tracing can
trace the preempt_{enable,disable} calls that are traced, replace them
with preempt_{enable,disable}_notrace to prevent function tracing from
going into an infinite loop, and then it can fix the kernel hang issue.
By the way, it seems that this commit is a complement and improvement of
commit f93a1a00f2bd ("MIPS: Fix crash that occurs when function tracing
is enabled").
Signed-off-by: Tiezhu Yang <[email protected]>
Cc: Steven Rostedt <[email protected]>
---
arch/mips/lib/mips-atomic.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/mips/lib/mips-atomic.c b/arch/mips/lib/mips-atomic.c
index de03838..a9b72ea 100644
--- a/arch/mips/lib/mips-atomic.c
+++ b/arch/mips/lib/mips-atomic.c
@@ -37,7 +37,7 @@
*/
notrace void arch_local_irq_disable(void)
{
- preempt_disable();
+ preempt_disable_notrace();
__asm__ __volatile__(
" .set push \n"
@@ -53,7 +53,7 @@ notrace void arch_local_irq_disable(void)
: /* no inputs */
: "memory");
- preempt_enable();
+ preempt_enable_notrace();
}
EXPORT_SYMBOL(arch_local_irq_disable);
@@ -61,7 +61,7 @@ notrace unsigned long arch_local_irq_save(void)
{
unsigned long flags;
- preempt_disable();
+ preempt_disable_notrace();
__asm__ __volatile__(
" .set push \n"
@@ -78,7 +78,7 @@ notrace unsigned long arch_local_irq_save(void)
: /* no inputs */
: "memory");
- preempt_enable();
+ preempt_enable_notrace();
return flags;
}
@@ -88,7 +88,7 @@ notrace void arch_local_irq_restore(unsigned long flags)
{
unsigned long __tmp1;
- preempt_disable();
+ preempt_disable_notrace();
__asm__ __volatile__(
" .set push \n"
@@ -106,7 +106,7 @@ notrace void arch_local_irq_restore(unsigned long flags)
: "0" (flags)
: "memory");
- preempt_enable();
+ preempt_enable_notrace();
}
EXPORT_SYMBOL(arch_local_irq_restore);
--
2.1.0
On Sat, May 15, 2021 at 07:02:01PM +0800, Tiezhu Yang wrote:
> When update the latest mainline kernel with the following three configs,
> the kernel hangs during startup:
>
> (1) CONFIG_FUNCTION_GRAPH_TRACER=y
> (2) CONFIG_PREEMPT_TRACER=y
> (3) CONFIG_FTRACE_STARTUP_TEST=y
>
> When update the latest mainline kernel with the above two configs (1)
> and (2), the kernel starts normally, but it still hangs when execute
> the following command:
>
> echo "function_graph" > /sys/kernel/debug/tracing/current_tracer
>
> Without CONFIG_PREEMPT_TRACER=y, the above two kinds of kernel hangs
> disappeared, so it seems that CONFIG_PREEMPT_TRACER has some influences
> with function_graph tracer at the first glance.
>
> I use ejtag to find out the epc address is related with preempt_enable()
> in the file arch/mips/lib/mips-atomic.c, because function tracing can
> trace the preempt_{enable,disable} calls that are traced, replace them
> with preempt_{enable,disable}_notrace to prevent function tracing from
> going into an infinite loop, and then it can fix the kernel hang issue.
>
> By the way, it seems that this commit is a complement and improvement of
> commit f93a1a00f2bd ("MIPS: Fix crash that occurs when function tracing
> is enabled").
>
> Signed-off-by: Tiezhu Yang <[email protected]>
> Cc: Steven Rostedt <[email protected]>
> ---
> arch/mips/lib/mips-atomic.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
applied to mips-fixes.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]