linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Cc: Ian Rogers <irogers@google.com>,
	Madhavan Srinivasan <maddy@linux.ibm.com>,
	Nageswara Sastry <rnsastry@linux.ibm.com>,
	Kajol Jain <kjain@linux.ibm.com>,
	linux-perf-users@vger.kernel.org, Jiri Olsa <jolsa@kernel.org>,
	Disha Goel <disgoel@linux.vnet.ibm.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] perf test bpf: Skip test if kernel-debuginfo is not present
Date: Wed, 14 Dec 2022 12:51:34 -0300	[thread overview]
Message-ID: <Y5nxBuZ2AmKQh93a@kernel.org> (raw)
In-Reply-To: <6D5F1D8A-47FF-46CF-8251-20BABDF283F6@linux.vnet.ibm.com>

Em Tue, Dec 13, 2022 at 03:21:03PM +0530, Athira Rajeev escreveu:
> > On 13-Dec-2022, at 12:27 AM, Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > Em Thu, Nov 03, 2022 at 12:27:01PM +0530, Athira Rajeev escreveu:
> >>> On 28-Oct-2022, at 9:12 PM, Kajol Jain <kjain@linux.ibm.com> wrote:
> >>> 
> >>> Perf BPF filter test fails in environment where "kernel-debuginfo"
> >>> is not installed.
> >>> 
> >>> Test failure logs:
> >>> <<>>
> >>> 42: BPF filter                            :
> >>> 42.1: Basic BPF filtering                 : Ok
> >>> 42.2: BPF pinning                         : Ok
> >>> 42.3: BPF prologue generation             : FAILED!
> >>> <<>>
> >>> 
> >>> Enabling verbose option provided debug logs, which says debuginfo
> >>> needs to be installed. Snippet of verbose logs:
> >>> 
> >>> <<>>
> >>> 42.3: BPF prologue generation                                       :
> >>> --- start ---
> >>> test child forked, pid 28218
> >>> <<>>
> >>> Rebuild with CONFIG_DEBUG_INFO=y, or install an appropriate debuginfo
> >>> package.
> >>> bpf_probe: failed to convert perf probe events
> >>> Failed to add events selected by BPF
> >>> test child finished with -1
> >>> ---- end ----
> >>> BPF filter subtest 3: FAILED!
> >>> <<>>
> >>> 
> >>> Here subtest, "BPF prologue generation" failed and
> >>> logs shows debuginfo is needed. After installing
> >>> kernel-debuginfo package, testcase passes.
> >>> 
> >>> Subtest "BPF prologue generation" failed because, the "do_test"
> >>> function returns "TEST_FAIL" without checking the error type
> >>> returned by "parse_events_load_bpf_obj" function.
> >>> Function parse_events_load_bpf_obj can also return error of type
> >>> "-ENOENT" incase kernel-debuginfo package is not installed. Fix this
> >>> by adding check for -ENOENT error.
> >>> 
> >>> Test result after the patch changes:
> >>> 
> >>> Test failure logs:
> >>> <<>>
> >>> 42: BPF filter                 :
> >>> 42.1: Basic BPF filtering      : Ok
> >>> 42.2: BPF pinning              : Ok
> >>> 42.3: BPF prologue generation  : Skip (clang/debuginfo isn't
> >>> installed or environment missing BPF support)
> >>> 
> >>> Fixes: ba1fae431e74bb42 ("perf test: Add 'perf test BPF'")
> >>> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
> >>> Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
> >>> ---
> >>> tools/perf/tests/bpf.c | 6 +++++-
> >>> 1 file changed, 5 insertions(+), 1 deletion(-)
> >>> 
> >>> diff --git a/tools/perf/tests/bpf.c b/tools/perf/tests/bpf.c
> >>> index 17c023823713..57cecadc1da2 100644
> >>> --- a/tools/perf/tests/bpf.c
> >>> +++ b/tools/perf/tests/bpf.c
> >>> @@ -126,6 +126,10 @@ static int do_test(struct bpf_object *obj, int (*func)(void),
> >>> 
> >>> 	err = parse_events_load_bpf_obj(&parse_state, &parse_state.list, obj, NULL);
> >>> 	parse_events_error__exit(&parse_error);
> >>> +	if (err == -ENOENT) {
> >>> +		pr_debug("Failed to add events selected by BPF, debuginfo package not installed\n");
> >>> +		return TEST_SKIP;
> >>> +	}
> >> 
> >> Hi Kajol,
> >> 
> >> Here, you have used ENOENT to skip the test. But there could be other places in the code path for “parse_events_load_bpf_obj”
> >> which also returns ENOENT. In that case, for any exit that returns ENOENT, test will get skipped.
> >> 
> >> Can we look at the logs, example we have this in commit logs:
> >> 
> >> 	Rebuild with CONFIG_DEBUG_INFO=y, or install an appropriate debuginfo
> >> 	package.
> >> 
> >> so as to decide whether to skip for debug info ?
> > 
> > Kajol?
 
> Hi Arnaldo, looking for your suggestion on how to handle the case where debuginfo is missing.
 
> Here the bpf test fails because of missing debuginfo. The function
> which goes through the debuginfo check is "parse_events_load_bpf_obj"
> . parse_events_load_bpf_obj internally calls "open_debuginfo" which
> returns ENOENT when debuginfo is missing. The patch fix from Kajol is
> to skip the test using error code ENOENT for debuginfo.

Lets see:

root@roc-rk3399-pc:~# uname -a
Linux roc-rk3399-pc 6.1.0-rc5-00123-g4dd7ff4a0311 #2 SMP PREEMPT Wed Nov 16 19:55:11 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
root@roc-rk3399-pc:~# perf probe -x ~/bin/perf open_debuginfo
Added new event:
  probe_perf:open_debuginfo (on open_debuginfo in /home/acme/bin/perf)

You can now use it in all perf tools, such as:

	perf record -e probe_perf:open_debuginfo -aR sleep 1

root@roc-rk3399-pc:~#

root@roc-rk3399-pc:~# perf trace --call-graph=dwarf -a -e probe_perf:* perf test bpf
 40: LLVM search and compile                                         :
 40.1: Basic BPF llvm compile                                        : Ok
 40.3: Compile source for BPF prologue generation                    : FAILED!
 40.4: Compile source for BPF relocation                             : Ok
 42: BPF filter                                                      :
 42.1: Basic BPF filtering                                           :     0.000 perf/38363 probe_perf:open_debuginfo(__probe_ip: 187650778659428)
                                       open_debuginfo (/home/acme/bin/perf)
                                       try_to_find_probe_trace_events (inlined)
                                       convert_to_probe_trace_events (inlined)
                                       convert_perf_probe_events (/home/acme/bin/perf)
                                       bpf__probe (/home/acme/bin/perf)
                                       parse_events_load_bpf_obj (/home/acme/bin/perf)
                                       do_test (/home/acme/bin/perf)
 FAILED!
 42.2: BPF pinning                                                   :  5594.218 perf/38582 probe_perf:open_debuginfo(__probe_ip: 187650778659428)
                                       open_debuginfo (/home/acme/bin/perf)
                                       try_to_find_probe_trace_events (inlined)
                                       convert_to_probe_trace_events (inlined)
                                       convert_perf_probe_events (/home/acme/bin/perf)
                                       bpf__probe (/home/acme/bin/perf)
                                       parse_events_load_bpf_obj (/home/acme/bin/perf)
                                       do_test (/home/acme/bin/perf)
 FAILED!
 42.3: BPF prologue generation                                       : FAILED!
 63: Test libpfm4 support                                            :
 99: perf stat --bpf-counters test                                   : Skip
100: perf stat --bpf-counters --for-each-cgroup test                 : Skip
root@roc-rk3399-pc:~#

So that is the callchains leading to open_debuginfo(), perhaps we should
return ENODATA at try_to_find_probe_trace_events() when open_debuginfo()
fails?

⬢[acme@toolbox perf]$ find tools/perf/ -name "*.[ch]" | xargs grep try_to_find_probe_trace_events
tools/perf/util/probe-event.c:static int try_to_find_probe_trace_events(struct perf_probe_event *pev,
tools/perf/util/probe-event.c:static int try_to_find_probe_trace_events(struct perf_probe_event *pev,
tools/perf/util/probe-event.c:	ret = try_to_find_probe_trace_events(pev, tevs);
⬢[acme@toolbox perf]$ 

Also it returns ENOENT as well when not finding the probe point... There
we should return perhaps ENOSYM?
 
> But issue with using this return code is that, there are other places
> in the code path for "parse_events_load_bpf_obj" which also returns
> ENOENT. In that case, for any exit path that returns ENOENT, test will
> get skipped.  Hence looking for an alternative way to identify missing
> debuginfo to skip the test. Please share your thoughts on this.

See above.

- Arnaldo

  reply	other threads:[~2022-12-14 15:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-28 15:42 [PATCH] perf test bpf: Skip test if kernel-debuginfo is not present Kajol Jain
2022-11-03  6:57 ` Athira Rajeev
2022-12-12 18:57   ` Arnaldo Carvalho de Melo
2022-12-13  9:51     ` Athira Rajeev
2022-12-14 15:51       ` Arnaldo Carvalho de Melo [this message]
     [not found]         ` <3F25062C-EA96-4745-B4E4-1A0375E29FA8@linux.vnet.ibm.com>
2023-01-02 14:23           ` 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=Y5nxBuZ2AmKQh93a@kernel.org \
    --to=acme@kernel.org \
    --cc=atrajeev@linux.vnet.ibm.com \
    --cc=disgoel@linux.vnet.ibm.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kjain@linux.ibm.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=rnsastry@linux.ibm.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).