diff options
author | Ding Tianhong <dingtianhong@huawei.com> | 2017-08-10 05:52:45 +0300 |
---|---|---|
committer | Daniel Lezcano <daniel.lezcano@linaro.org> | 2017-08-11 17:01:43 +0300 |
commit | adb4f11e0a8f4e29900adb2b7af28b6bbd5c1fa4 (patch) | |
tree | 4c94934dec69bf5c73623de49c60a67f9287a289 /drivers | |
parent | 599dc457c79bde8bd4fe8bbb2ba1f30ef3d7a5c8 (diff) | |
download | linux-adb4f11e0a8f4e29900adb2b7af28b6bbd5c1fa4.tar.xz |
clocksource/drivers/arm_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.
This problem is similar to the fixed by upstream commit 96b3d28bf4
("sched/clock: Prevent tracing recursion in sched_clock_cpu()").
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>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Diffstat (limited to 'drivers')
0 files changed, 0 insertions, 0 deletions