All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Cc: Disha Goel <disgoel@linux.vnet.ibm.com>,
	Kajol Jain <kjain@linux.ibm.com>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	bpf@vger.kernel.org
Subject: Re: [PATCH] perf test: Switch basic bpf filtering test to use syscall tracepoint
Date: Mon, 23 Jan 2023 09:58:39 -0300	[thread overview]
Message-ID: <Y86Ef0KKlor+XsXm@kernel.org> (raw)
In-Reply-To: <20230123083224.276404-1-naveen.n.rao@linux.vnet.ibm.com>

Em Mon, Jan 23, 2023 at 02:02:24PM +0530, Naveen N. Rao escreveu:
> BPF filtering tests can sometime fail. Running the test in verbose mode
> shows the following:

Thanks, applied.

- Arnaldo

>   $ sudo perf test 42
>   42: BPF filter                                                      :
>   42.1: Basic BPF filtering                                           : FAILED!
>   42.2: BPF pinning                                                   : Skip
>   42.3: BPF prologue generation                                       : Skip
>   $ perf --version
>   perf version 4.18.0-425.3.1.el8.ppc64le
>   $ sudo perf test -v 42
>   42: BPF filter                                                      :
>   42.1: Basic BPF filtering                                           :
>   --- start ---
>   test child forked, pid 711060
>   ...
>   bpf: config 'func=do_epoll_wait' is ok
>   Looking at the vmlinux_path (8 entries long)
>   Using /usr/lib/debug/lib/modules/4.18.0-425.3.1.el8.ppc64le/vmlinux for symbols
>   Open Debuginfo file: /usr/lib/debug/.build-id/81/56f5a07f92ccb62c5600ba0e4aacfb5f3a7534.debug
>   Try to find probe point from debuginfo.
>   Matched function: do_epoll_wait [4ef8cb0]
>   found inline addr: 0xc00000000061dbe4
>   Probe point found: __se_compat_sys_epoll_pwait+196
>   found inline addr: 0xc00000000061d9f4
>   Probe point found: __se_sys_epoll_pwait+196
>   found inline addr: 0xc00000000061d824
>   Probe point found: __se_sys_epoll_wait+36
>   Found 3 probe_trace_events.
>   Opening /sys/kernel/tracing//kprobe_events write=1
>   ...
>   BPF filter result incorrect, expected 56, got 56 samples
>   test child finished with -1
>   ---- end ----
>   BPF filter subtest 1: FAILED!
> 
> The statement above about the result being incorrect looks weird, and it
> is due to that particular perf build missing commit 3e11300cdfd5f1
> ("perf test: Fix bpf test sample mismatch reporting"). In reality, due
> to commit 4b04e0decd2518 ("perf test: Fix basic bpf filtering test"),
> perf expects there to be 56*3 samples.
> 
> However, the number of samples we receive is going to be dependent on
> where the probes are installed, which is dependent on where
> do_epoll_wait gets inlined. On s390x, it looks like probes at all the
> inlined locations are hit. But, that is not the case on ppc64le.
> 
> Fix this by switching the test to instead use the syscall tracepoint.
> This ensures that we will only ever install a single event enabling us
> to reliably determine the sample count.
> 
> Reported-by: Disha Goel <disgoel@linux.vnet.ibm.com>

> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
>  tools/perf/tests/bpf-script-example.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/perf/tests/bpf-script-example.c b/tools/perf/tests/bpf-script-example.c
> index 7981c69ed1b456..b638cc99d5ae56 100644
> --- a/tools/perf/tests/bpf-script-example.c
> +++ b/tools/perf/tests/bpf-script-example.c
> @@ -43,7 +43,7 @@ struct {
>  	__type(value, int);
>  } flip_table SEC(".maps");
>  
> -SEC("func=do_epoll_wait")
> +SEC("syscalls:sys_enter_epoll_pwait")
>  int bpf_func__SyS_epoll_pwait(void *ctx)
>  {
>  	int ind =0;
> 
> base-commit: 5670ebf54bd26482f57a094c53bdc562c106e0a9
> -- 
> 2.39.1
> 

-- 

- Arnaldo

  reply	other threads:[~2023-01-23 12:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-23  8:32 [PATCH] perf test: Switch basic bpf filtering test to use syscall tracepoint Naveen N. Rao
2023-01-23 12:58 ` Arnaldo Carvalho de Melo [this message]
2023-01-30  8:58 ` kajoljain
2023-01-30 14:09   ` 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=Y86Ef0KKlor+XsXm@kernel.org \
    --to=acme@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=disgoel@linux.vnet.ibm.com \
    --cc=kjain@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=naveen.n.rao@linux.vnet.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.