From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RESEND] arm64: arch_timer: fix the infinite recursion when enable ftrace and erratum workaround
Date: Mon, 10 Jul 2017 12:22:29 +0100 [thread overview]
Message-ID: <20170710112229.GA18040@leverpostej> (raw)
In-Reply-To: <321e4c16-aa14-beee-b6dc-36e19e5ec35a@huawei.com>
On Sun, Jul 09, 2017 at 04:30:54PM +0800, Ding Tianhong wrote:
> When enable preempt and debug ftrace, and perform the following steps, the
> system will hang:
> mount -t debugfs nodev /sys/kernel/debug/
> cd /sys/kernel/debug/tracing/
> echo function_graph > current_tracer
>
> This is because tracing the preempt_disable/enable calls would cause
> trace_clock() which would get local timer to go into infinite recursion
> when enable the arch timer erratum workaround for some chips, so Prevent
> tracing of preempt_disable/enable() in arch_timer_reg_read_stable().
>
> This problem is similar to the fixed by upstream commit 96b3d28bf4
> ("sched/clock: Prevent tracing recursion in sched_clock_cpu()").
As I mentioned before, the patch itself looks fine to me, but the commit
message is somewhat difficult to read.
Can we please change this to:
arm64: arch_timer: avoid infinite recursion when ftrace is enabled
On platforms with an arch timer erratum workaround, it's possible for
arch_timer_reg_read_stable() to recurse into itself when certain
tracing options are enabled, leading to stack overflows and related
problems.
For example, when PREEMPT_TRACER and FUNCTION_GRAPH_TRACER are
selected, it's possible to trigger this with:
$ mount -t debugfs nodev /sys/kernel/debug/
$ echo function_graph > /sys/kernel/debug/tracing/current_tracer
The problem is that in such cases, preempt_disable() instrumentation
attempts to acquire a timestamp via trace_clock(), resulting in a call
back to arch_timer_reg_read_stable(), and hence recursion.
This patch changes arch_timer_reg_read_stable() to use
preempt_{disable,enable}_notrace(), which avoids this.
With that commit message:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Daniel, Thomas, would you be happy to fold that in when picking this? Or
would you prefer that I fix this up and resend?
Thanks,
Mark.
> Fixes: 6acc71ccac71 ("arm64: arch_timer: Allows a CPU-specific erratum to only affect a subset of CPUs")
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
> arch/arm64/include/asm/arch_timer.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
> index 74d08e4..67bb7a4 100644
> --- a/arch/arm64/include/asm/arch_timer.h
> +++ b/arch/arm64/include/asm/arch_timer.h
> @@ -65,13 +65,13 @@ struct arch_timer_erratum_workaround {
> u64 _val; \
> if (needs_unstable_timer_counter_workaround()) { \
> const struct arch_timer_erratum_workaround *wa; \
> - preempt_disable(); \
> + preempt_disable_notrace(); \
> wa = __this_cpu_read(timer_unstable_counter_workaround); \
> if (wa && wa->read_##reg) \
> _val = wa->read_##reg(); \
> else \
> _val = read_sysreg(reg); \
> - preempt_enable(); \
> + preempt_enable_notrace(); \
> } else { \
> _val = read_sysreg(reg); \
> } \
> --
> 1.9.0
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Ding Tianhong <dingtianhong@huawei.com>,
Marc Zyngier <marc.zyngier@arm.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>, LinuxArm <linuxarm@huawei.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RESEND] arm64: arch_timer: fix the infinite recursion when enable ftrace and erratum workaround
Date: Mon, 10 Jul 2017 12:22:29 +0100 [thread overview]
Message-ID: <20170710112229.GA18040@leverpostej> (raw)
In-Reply-To: <321e4c16-aa14-beee-b6dc-36e19e5ec35a@huawei.com>
On Sun, Jul 09, 2017 at 04:30:54PM +0800, Ding Tianhong wrote:
> When enable preempt and debug ftrace, and perform the following steps, the
> system will hang:
> mount -t debugfs nodev /sys/kernel/debug/
> cd /sys/kernel/debug/tracing/
> echo function_graph > current_tracer
>
> This is because tracing the preempt_disable/enable calls would cause
> trace_clock() which would get local timer to go into infinite recursion
> when enable the arch timer erratum workaround for some chips, so Prevent
> tracing of preempt_disable/enable() in arch_timer_reg_read_stable().
>
> This problem is similar to the fixed by upstream commit 96b3d28bf4
> ("sched/clock: Prevent tracing recursion in sched_clock_cpu()").
As I mentioned before, the patch itself looks fine to me, but the commit
message is somewhat difficult to read.
Can we please change this to:
arm64: arch_timer: avoid infinite recursion when ftrace is enabled
On platforms with an arch timer erratum workaround, it's possible for
arch_timer_reg_read_stable() to recurse into itself when certain
tracing options are enabled, leading to stack overflows and related
problems.
For example, when PREEMPT_TRACER and FUNCTION_GRAPH_TRACER are
selected, it's possible to trigger this with:
$ mount -t debugfs nodev /sys/kernel/debug/
$ echo function_graph > /sys/kernel/debug/tracing/current_tracer
The problem is that in such cases, preempt_disable() instrumentation
attempts to acquire a timestamp via trace_clock(), resulting in a call
back to arch_timer_reg_read_stable(), and hence recursion.
This patch changes arch_timer_reg_read_stable() to use
preempt_{disable,enable}_notrace(), which avoids this.
With that commit message:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Daniel, Thomas, would you be happy to fold that in when picking this? Or
would you prefer that I fix this up and resend?
Thanks,
Mark.
> Fixes: 6acc71ccac71 ("arm64: arch_timer: Allows a CPU-specific erratum to only affect a subset of CPUs")
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
> arch/arm64/include/asm/arch_timer.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
> index 74d08e4..67bb7a4 100644
> --- a/arch/arm64/include/asm/arch_timer.h
> +++ b/arch/arm64/include/asm/arch_timer.h
> @@ -65,13 +65,13 @@ struct arch_timer_erratum_workaround {
> u64 _val; \
> if (needs_unstable_timer_counter_workaround()) { \
> const struct arch_timer_erratum_workaround *wa; \
> - preempt_disable(); \
> + preempt_disable_notrace(); \
> wa = __this_cpu_read(timer_unstable_counter_workaround); \
> if (wa && wa->read_##reg) \
> _val = wa->read_##reg(); \
> else \
> _val = read_sysreg(reg); \
> - preempt_enable(); \
> + preempt_enable_notrace(); \
> } else { \
> _val = read_sysreg(reg); \
> } \
> --
> 1.9.0
>
>
next prev parent reply other threads:[~2017-07-10 11:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-09 8:30 [PATCH RESEND] arm64: arch_timer: fix the infinite recursion when enable ftrace and erratum workaround Ding Tianhong
2017-07-09 8:30 ` Ding Tianhong
2017-07-10 6:12 ` Hanjun Guo
2017-07-10 6:12 ` Hanjun Guo
2017-07-10 11:22 ` Mark Rutland [this message]
2017-07-10 11:22 ` Mark Rutland
2017-07-10 13:54 ` Marc Zyngier
2017-07-10 13:54 ` Marc Zyngier
2017-07-26 2:42 ` Ding Tianhong
2017-07-26 2:42 ` Ding Tianhong
2017-07-31 15:33 ` Daniel Lezcano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170710112229.GA18040@leverpostej \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.