linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
To: Leo Yan <leo.yan@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Mike Leach <mike.leach@linaro.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	bpf@vger.kernel.org
Subject: Re: [PATCH v2 1/4] perf trace: Exit when build eBPF program failure
Date: Thu, 6 Jun 2019 10:30:19 -0300	[thread overview]
Message-ID: <20190606133019.GA30166@kernel.org> (raw)
In-Reply-To: <20190606094845.4800-2-leo.yan@linaro.org>

Em Thu, Jun 06, 2019 at 05:48:42PM +0800, Leo Yan escreveu:
> On my Juno board with ARM64 CPUs, perf trace command reports the eBPF
> program building failure but the command will not exit and continue to
> run.  If we define an eBPF event in config file, the event will be
> parsed with below flow:
> 
>   perf_config()
>     `> trace__config()
> 	 `> parse_events_option()
> 	      `> parse_events__scanner()
> 	           `-> parse_events_parse()
> 	                 `> parse_events_load_bpf()
> 	                      `> llvm__compile_bpf()
> 
> Though the low level functions return back error values when detect eBPF
> building failure, but parse_events_option() returns 1 for this case and

(gdb) n
parse_events__scanner (str=0xb9d170 "/home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o", parse_state=0x7fffffff7fa0,
    start_token=258) at util/parse-events.c:1870
1870		parse_events__delete_buffer(buffer, scanner);
(gdb) n
1871		parse_events_lex_destroy(scanner);
(gdb) n
1872		return ret;
(gdb) p ret
$53 = 1
(gdb) bt
#0  parse_events__scanner (str=0xb9d170 "/home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o", parse_state=0x7fffffff7fa0,
    start_token=258) at util/parse-events.c:1872
#1  0x000000000050a926 in parse_events (evlist=0xb9e5d0, str=0xb9d170 "/home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o",
    err=0x7fffffff8020) at util/parse-events.c:1907
#2  0x000000000050ad94 in parse_events_option (opt=0x7fffffff8080,
    str=0xb9d170 "/home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o", unset=0) at util/parse-events.c:2007
#3  0x0000000000497fa8 in trace__config (var=0x7fffffff8150 "trace.add_events",
    value=0xb9d170 "/home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o", arg=0x7fffffffa1c0) at builtin-trace.c:3706
#4  0x00000000004e9a79 in perf_config (fn=0x497ee4 <trace__config>, data=0x7fffffffa1c0) at util/config.c:738
#5  0x0000000000498c97 in cmd_trace (argc=2, argv=0x7fffffffd690) at builtin-trace.c:3865
#6  0x00000000004d8c17 in run_builtin (p=0xa0e600 <commands+576>, argc=2, argv=0x7fffffffd690) at perf.c:303
#7  0x00000000004d8e84 in handle_internal_command (argc=2, argv=0x7fffffffd690) at perf.c:355
#8  0x00000000004d8fd3 in run_argv (argcp=0x7fffffffd4ec, argv=0x7fffffffd4e0) at perf.c:399
#9  0x00000000004d933f in main (argc=2, argv=0x7fffffffd690) at perf.c:521
(gdb)

So its parse_events__scanner() that returns 1, parse_events() propagate
that and:

parse_events_option (opt=0x7fffffff8080, str=0xb9d170 "/home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o", unset=0)
    at util/parse-events.c:2009
2009		if (ret) {
(gdb) p ret
$56 = 1
(gdb) n
2010			parse_events_print_error(&err, str);
(gdb) n
event syntax error: '/home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o'
                     \___ Kernel verifier blocks program loading

(add -v to see detail)
2011			fprintf(stderr, "Run 'perf list' for a list of valid events\n");
(gdb)

So the -4007 error is printed, and all we can say is that parsing events
failed, but we end up not propagating that error back when we use
parse_events_option(), we could use instead:

        struct parse_events_error err = { .idx = 0, };
        int ret = parse_events(evlist, str, &err);

And make parse_events_error have the raw err, i.e. -4007 in this case:

        [ERRCODE_OFFSET(VERIFY)]        = "Kernel verifier blocks program loading",

In your case would be something else, I'm just trying to load the
precompiled .o that does things the BPF kernel verifier doesn't like.

So yeah, your patch looks ok, i.e. parse_events_option() returning !0
should make trace__config() return -1.

But see below:

- Arnaldo

> trace__config() passes 1 to perf_config(); perf_config() doesn't treat
> the returned value 1 as failure and it continues to parse other
> configurations.  Thus the perf command continues to run even without
> enabling eBPF event successfully.
> 
> This patch changes error handling in trace__config(), when it detects
> failure it will return -1 rather than directly pass error value (1);
> finally, perf_config() will directly bail out and perf will exit for
> this case.
> 
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
>  tools/perf/builtin-trace.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
> index 54b2d0fd0d02..4b5d004aab74 100644
> --- a/tools/perf/builtin-trace.c
> +++ b/tools/perf/builtin-trace.c
> @@ -3664,6 +3664,14 @@ static int trace__config(const char *var, const char *value, void *arg)
>  					       "event selector. use 'perf list' to list available events",
>  					       parse_events_option);
>  		err = parse_events_option(&o, value, 0);
> +
> +		/*
> +		 * When parse option successfully parse_events_option() will
> +		 * return 0, otherwise means the paring failure.  And it
> +		 * returns 1 for eBPF program building failure; so adjust the
> +		 * err value to -1 for the failure.
> +		 */
> +		err = err ? -1 : 0;

I'll rewrite the comment above to make it more succint and fix things
like 'paring' (parsing):

		/*
		 * parse_events_option() returns !0 to indicate failure
		 * while the perf_config code that calls trace__config()
		 * expects < 0 returns to indicate error, so:
		 */

		 if (err)
		 	err = -1;
>  	} else if (!strcmp(var, "trace.show_timestamp")) {
>  		trace->show_tstamp = perf_config_bool(var, value);
>  	} else if (!strcmp(var, "trace.show_duration")) {
> -- 
> 2.17.1

-- 

- Arnaldo

  reply	other threads:[~2019-06-06 13:30 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-06  9:48 [PATCH v2 0/4] perf augmented_raw_syscalls: Support for arm64 Leo Yan
2019-06-06  9:48 ` [PATCH v2 1/4] perf trace: Exit when build eBPF program failure Leo Yan
2019-06-06 13:30   ` Arnaldo Carvalho de Melo [this message]
2019-06-06 13:34     ` Arnaldo Carvalho de Melo
2019-06-10  7:38       ` Leo Yan
2019-06-06 13:56     ` Leo Yan
2019-06-06  9:48 ` [PATCH v2 2/4] perf augmented_raw_syscalls: Remove duplicate macros Leo Yan
2019-06-06  9:48 ` [PATCH v2 3/4] perf augmented_raw_syscalls: Support arm64 raw syscalls Leo Yan
2019-06-06 13:38   ` Arnaldo Carvalho de Melo
2019-06-06 13:46     ` Arnaldo Carvalho de Melo
2019-06-06 14:05       ` Arnaldo Carvalho de Melo
2019-06-06 14:12     ` Leo Yan
2019-06-06 14:44       ` Arnaldo Carvalho de Melo
2019-06-07  9:58         ` Leo Yan
2019-06-09 13:18           ` Leo Yan
2019-06-10 18:47             ` Arnaldo Carvalho de Melo
2019-06-11  4:18               ` Leo Yan
2019-06-12  2:49                 ` Arnaldo Carvalho de Melo
2019-06-13 18:15                   ` Arnaldo Carvalho de Melo
2019-06-15  5:52                     ` Leo Yan
2019-06-22  6:44                     ` [tip:perf/core] perf trace: Fix exclusion of not available syscall names from selector list tip-bot for Arnaldo Carvalho de Melo
2019-06-17 19:53               ` [tip:perf/core] perf trace: Skip unknown syscalls when expanding strace like syscall groups tip-bot for Arnaldo Carvalho de Melo
2019-06-06  9:48 ` [PATCH v2 4/4] perf augmented_raw_syscalls: Document clang configuration Leo Yan
2019-06-06 14:08   ` Arnaldo Carvalho de Melo
2019-06-06 14:35     ` Leo Yan
2019-06-06 18:29       ` Arnaldo Carvalho de Melo
2019-06-07 14:38         ` Leo Yan
2019-06-07 18:33           ` Arnaldo Carvalho de Melo

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=20190606133019.GA30166@kernel.org \
    --to=arnaldo.melo@gmail.com \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jolsa@redhat.com \
    --cc=kafai@fb.com \
    --cc=leo.yan@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=mike.leach@linaro.org \
    --cc=namhyung@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=suzuki.poulose@arm.com \
    --cc=yhs@fb.com \
    /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).