Commit 3ce70b2e authored by Will Deacon's avatar Will Deacon

ARM: hw_breakpoint: disallow per-cpu breakpoints without overflow handler

Single-stepping a breakpoint requires us to disable it temporarily so that
we don't get stuck in a recursive debug trap. With per-cpu breakpoints this
presents a problem where an interrupt can be taken before the single-step has
completed and a new task is eventually scheduled. This new task will not
hit the breakpoint because it will have been disabled during the previous
handling code.

This patch disallows per-cpu breakpoints on ARM when an overflow handler
is not present. A similar effect can be created by placing breakpoints on
a shell and then running applications there.
Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
parent 9ebb3cbc
...@@ -622,10 +622,12 @@ int arch_validate_hwbkpt_settings(struct perf_event *bp) ...@@ -622,10 +622,12 @@ int arch_validate_hwbkpt_settings(struct perf_event *bp)
* Currently we rely on an overflow handler to take * Currently we rely on an overflow handler to take
* care of single-stepping the breakpoint when it fires. * care of single-stepping the breakpoint when it fires.
* In the case of userspace breakpoints on a core with V7 debug, * In the case of userspace breakpoints on a core with V7 debug,
* we can use the mismatch feature as a poor-man's hardware single-step. * we can use the mismatch feature as a poor-man's hardware
* single-step, but this only works for per-task breakpoints.
*/ */
if (WARN_ONCE(!bp->overflow_handler && if (WARN_ONCE(!bp->overflow_handler &&
(arch_check_bp_in_kernelspace(bp) || !core_has_mismatch_brps()), (arch_check_bp_in_kernelspace(bp) || !core_has_mismatch_brps()
|| !bp->hw.bp_target),
"overflow handler required but none found")) { "overflow handler required but none found")) {
ret = -EINVAL; ret = -EINVAL;
} }
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment