From: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
To: Leo Yan <leo.yan@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Will Deacon <will@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
Brajeswar Ghosh <brajeswar.linux@gmail.com>,
Souptick Joarder <jrdr.linux@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Michael Petlan <mpetlan@redhat.com>,
Song Liu <songliubraving@fb.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 3/3] perf tests: Disable bp_signal testing for arm64
Date: Fri, 18 Oct 2019 14:59:19 -0300 [thread overview]
Message-ID: <20191018175919.GC1797@kernel.org> (raw)
In-Reply-To: <20191018085531.6348-3-leo.yan@linaro.org>
Em Fri, Oct 18, 2019 at 04:55:31PM +0800, Leo Yan escreveu:
> As there have several discussions for enabling Perf breakpoint signal
> testing on arm64 platform; arm64 needs to rely on single-step to execute
> the breakpointed instruction and then reinstall the breakpoint exception
> handler. But if hook the breakpoint with a signal, the signal handler
> will do the stepping rather than the breakpointed instruction, this
> causes infinite loops as below:
>
> Kernel space | Userspace
> -----------------------------------|--------------------------------
> | __test_function() -> hit
> | breakpoint
> breakpoint_handler() |
> `-> user_enable_single_step() |
> do_signal() |
> | sig_handler() -> Step one
> | instruction and
> | trap to kernel
> single_step_handler() |
> `-> reinstall_suspended_bps() |
> | __test_function() -> hit
> | breakpoint again and
> | repeat up flow infinitely
>
> As Will Deacon mentioned [1]: "that we require the overflow handler to
> do the stepping on arm/arm64, which is relied upon by GDB/ptrace. The
> hw_breakpoint code is a complete disaster so my preference would be to
> rip out the perf part and just implement something directly in ptrace,
> but it's a pretty horrible job". Though Will commented this on arm
> architecture, but the comment also can apply on arm64 architecture.
>
> For complete information, I searched online and found a few years back,
> Wang Nan sent one patch 'arm64: Store breakpoint single step state into
> pstate' [2]; the patch tried to resolve this issue by avoiding single
> stepping in signal handler and defer to enable the signal stepping when
> return to __test_function(). The fixing was not merged due to the
> concern for missing to handle different usage cases.
>
> Based on the info, the most feasible way is to skip Perf breakpoint
> signal testing for arm64 and this could avoid the duplicate
> investigation efforts when people see the failure. This patch skips
> this case on arm64 platform, which is same with arm architecture.
Ok, applying,
- Arnaldo
> [1] https://lkml.org/lkml/2018/11/15/205
> [2] https://lkml.org/lkml/2015/12/23/477
>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
> tools/perf/tests/bp_signal.c | 15 ++++++---------
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/tools/perf/tests/bp_signal.c b/tools/perf/tests/bp_signal.c
> index c1c2c13de254..166f411568a5 100644
> --- a/tools/perf/tests/bp_signal.c
> +++ b/tools/perf/tests/bp_signal.c
> @@ -49,14 +49,6 @@ asm (
> "__test_function:\n"
> "incq (%rdi)\n"
> "ret\n");
> -#elif defined (__aarch64__)
> -extern void __test_function(volatile long *ptr);
> -asm (
> - ".globl __test_function\n"
> - "__test_function:\n"
> - "str x30, [x0]\n"
> - "ret\n");
> -
> #else
> static void __test_function(volatile long *ptr)
> {
> @@ -302,10 +294,15 @@ bool test__bp_signal_is_supported(void)
> * stepping into the SIGIO handler and getting stuck on the
> * breakpointed instruction.
> *
> + * Since arm64 has the same issue with arm for the single-step
> + * handling, this case also gets suck on the breakpointed
> + * instruction.
> + *
> * Just disable the test for these architectures until these
> * issues are resolved.
> */
> -#if defined(__powerpc__) || defined(__s390x__) || defined(__arm__)
> +#if defined(__powerpc__) || defined(__s390x__) || defined(__arm__) || \
> + defined(__aarch64__)
> return false;
> #else
> return true;
> --
> 2.17.1
--
- Arnaldo
next prev parent reply other threads:[~2019-10-18 17:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-18 8:55 [PATCH v1 1/3] perf tests: Remove needless headers for bp_account Leo Yan
2019-10-18 8:55 ` [PATCH v1 2/3] perf tests bp_account: Add dedicated checking helper is_supported() Leo Yan
2019-10-18 17:57 ` Arnaldo Carvalho de Melo
2019-10-21 23:18 ` [tip: perf/core] " tip-bot2 for Leo Yan
2019-10-18 8:55 ` [PATCH v1 3/3] perf tests: Disable bp_signal testing for arm64 Leo Yan
2019-10-18 17:59 ` Arnaldo Carvalho de Melo [this message]
2019-10-21 7:53 ` Leo Yan
2019-10-21 23:18 ` [tip: perf/core] " tip-bot2 for Leo Yan
2019-10-22 13:14 ` Will Deacon
2019-10-22 13:43 ` Leo Yan
2019-10-18 17:55 ` [PATCH v1 1/3] perf tests: Remove needless headers for bp_account Arnaldo Carvalho de Melo
2019-10-21 23:18 ` [tip: perf/core] " tip-bot2 for Leo Yan
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=20191018175919.GC1797@kernel.org \
--to=arnaldo.melo@gmail.com \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=brajeswar.linux@gmail.com \
--cc=f.fainelli@gmail.com \
--cc=jolsa@redhat.com \
--cc=jrdr.linux@gmail.com \
--cc=leo.yan@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=mpetlan@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=songliubraving@fb.com \
--cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).