IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
BPF filtering tests can sometime fail. Running the test in verbose mode
shows the following:
$ 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 3e11300cdf
("perf test: Fix bpf test sample mismatch reporting"). In reality, due
to commit 4b04e0decd ("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>
Cc: Kajol Jain <kjain@linux.ibm.com>
Cc: bpf@vger.kernel.org
Link: http://lore.kernel.org/lkml/20230123083224.276404-1-naveen.n.rao@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
7158005b4e