14 Oct, 2020
2 commits
-
Allow the CC compiler to accept a CFLAGS environment variable. This
doesn't change the code generated but makes it easier to integrate
running the shell script in build systems like bazel.Signed-off-by: Ian Rogers
Cc: Adrian Hunter
Cc: Alexander Shishkin
Cc: Alexios Zavras
Cc: Andi Kleen
Cc: Greg Kroah-Hartman
Cc: Igor Lubashev
Cc: Jiri Olsa
Cc: Kan Liang
Cc: Mark Rutland
Cc: Mathieu Poirier
Cc: Namhyung Kim
Cc: Nick Desaulniers
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Thomas Gleixner
Cc: Wei Li
Link: http://lore.kernel.org/lkml/20200306071110.130202-4-irogers@google.com
[ split from a larger patch ]
Signed-off-by: Arnaldo Carvalho de Melo -
The variable 'traceid_list' is defined in the header file cs-etm.h,
if multiple C files include cs-etm.h the compiler might complaint for
multiple definition of 'traceid_list'.To fix multiple definition error, move the definition of 'traceid_list'
into cs-etm.c.Fixes: cd8bfd8c973e ("perf tools: Add processing of coresight metadata")
Reported-by: Thomas Backlund
Signed-off-by: Leo Yan
Reviewed-by: Mathieu Poirier
Reviewed-by: Mike Leach
Tested-by: Mike Leach
Tested-by: Thomas Backlund
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Suzuki Poulouse
Cc: Tor Jeremiassen
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lore.kernel.org/lkml/20200505133642.4756-1-leo.yan@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo
08 Oct, 2020
1 commit
-
* tag 'v5.4.70': (3051 commits)
Linux 5.4.70
netfilter: ctnetlink: add a range check for l3/l4 protonum
ep_create_wakeup_source(): dentry name can change under you...
...Conflicts:
arch/arm/mach-imx/pm-imx6.c
arch/arm64/boot/dts/freescale/imx8mm-evk.dts
arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
drivers/crypto/caam/caamalg.c
drivers/gpu/drm/imx/dw_hdmi-imx.c
drivers/gpu/drm/imx/imx-ldb.c
drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c
drivers/mmc/host/sdhci-esdhc-imx.c
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
drivers/net/ethernet/freescale/enetc/enetc.c
drivers/net/ethernet/freescale/enetc/enetc_pf.c
drivers/thermal/imx_thermal.c
drivers/usb/cdns3/ep0.c
drivers/xen/swiotlb-xen.c
sound/soc/fsl/fsl_esai.c
sound/soc/fsl/fsl_sai.cSigned-off-by: Jason Liu
07 Oct, 2020
2 commits
-
[ Upstream commit 72f04da48a9828ba3ae8ac77bea648bda8b7d0ff ]
It would seem none of the kernel continuous integration does this:
$ cd tools/io_uring
$ makeOtherwise it may have noticed:
cc -Wall -Wextra -g -D_GNU_SOURCE -c -o io_uring-bench.o
io_uring-bench.c
io_uring-bench.c:133:12: error: static declaration of ‘gettid’
follows non-static declaration
133 | static int gettid(void)
| ^~~~~~
In file included from /usr/include/unistd.h:1170,
from io_uring-bench.c:27:
/usr/include/x86_64-linux-gnu/bits/unistd_ext.h:34:16: note:
previous declaration of ‘gettid’ was here
34 | extern __pid_t gettid (void) __THROW;
| ^~~~~~
make: *** [: io_uring-bench.o] Error 1The problem on Ubuntu 20.04 (with lk 5.9.0-rc5) is that unistd.h
already defines gettid(). So prefix the local definition with
"lk_".Signed-off-by: Douglas Gilbert
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin -
[ Upstream commit 21e9ba5373fc2cec608fd68301a1dbfd14df3172 ]
Ubuntu mainline builds for ppc64le are failing with the below error (*):
CALL /home/kernel/COD/linux/scripts/atomic/check-atomics.sh
DESCEND bpf/resolve_btfidsAuto-detecting system features:
... libelf: [ [32mon[m ]
... zlib: [ [32mon[m ]
... bpf: [ [31mOFF[m ]BPF API too old
make[6]: *** [Makefile:295: bpfdep] Error 1
make[5]: *** [Makefile:54: /home/kernel/COD/linux/debian/build/build-generic/tools/bpf/resolve_btfids//libbpf.a] Error 2
make[4]: *** [Makefile:71: bpf/resolve_btfids] Error 2
make[3]: *** [/home/kernel/COD/linux/Makefile:1890: tools/bpf/resolve_btfids] Error 2
make[2]: *** [/home/kernel/COD/linux/Makefile:335: __build_one_by_one] Error 2
make[2]: Leaving directory '/home/kernel/COD/linux/debian/build/build-generic'
make[1]: *** [Makefile:185: __sub-make] Error 2
make[1]: Leaving directory '/home/kernel/COD/linux'resolve_btfids needs to be build as a host binary and it needs libbpf.
However, libbpf Makefile hardcodes an include path utilizing $(ARCH).
This results in mixing of cross-architecture headers resulting in a
build failure.The specific header include path doesn't seem necessary for a libbpf
build. Hence, remove the same.(*) https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.9-rc3/ppc64el/log
Reported-by: Vaidyanathan Srinivasan
Signed-off-by: Naveen N. Rao
Signed-off-by: Daniel Borkmann
Acked-by: Andrii Nakryiko
Link: https://lore.kernel.org/bpf/20200902084246.1513055-1-naveen.n.rao@linux.vnet.ibm.com
Signed-off-by: Sasha Levin
01 Oct, 2020
23 commits
-
[ Upstream commit db6c6a0df840e3f52c84cc302cc1a08ba11a4416 ]
When a function is annotated with STACK_FRAME_NON_STANDARD, objtool
doesn't validate its code paths. It also skips sibling call detection
within the function.But sibling call detection is actually needed for the case where the
ignored function doesn't have any return instructions. Otherwise
objtool naively marks the function as implicit static noreturn, which
affects the reachability of its callers, resulting in "unreachable
instruction" warnings.Fix it by just enabling sibling call detection for ignored functions.
The 'insn->ignore' check in add_jump_destinations() is no longer needed
aftere6da9567959e ("objtool: Don't use ignore flag for fake jumps").
Fixes the following warning:
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_handle_exit_irqoff()+0x142: unreachable instruction
which triggers on an allmodconfig with CONFIG_GCOV_KERNEL unset.
Reported-by: Linus Torvalds
Signed-off-by: Josh Poimboeuf
Signed-off-by: Borislav Petkov
Acked-by: Linus Torvalds
Link: https://lkml.kernel.org/r/5b1e2536cdbaa5246b60d7791b76130a74082c62.1599751464.git.jpoimboe@redhat.com
Signed-off-by: Sasha Levin -
[ Upstream commit 8510895bafdbf7c4dd24c22946d925691135c2b2 ]
A big uncore event group is split into multiple small groups which only
include the uncore events from the same PMU. This has been supported in
the commit 3cdc5c2cb924a ("perf parse-events: Handle uncore event
aliases in small groups properly").If the event's PMU name starts to repeat, it must be a new event.
That can be used to distinguish the leader from other members.
But now it only compares the pointer of pmu_name
(leader->pmu_name == evsel->pmu_name).If we use "perf stat -M LLC_MISSES.PCIE_WRITE -a" on cascadelakex,
the event list is:evsel->name evsel->pmu_name
---------------------------------------------------------------
unc_iio_data_req_of_cpu.mem_write.part0 uncore_iio_4 (as leader)
unc_iio_data_req_of_cpu.mem_write.part0 uncore_iio_2
unc_iio_data_req_of_cpu.mem_write.part0 uncore_iio_0
unc_iio_data_req_of_cpu.mem_write.part0 uncore_iio_5
unc_iio_data_req_of_cpu.mem_write.part0 uncore_iio_3
unc_iio_data_req_of_cpu.mem_write.part0 uncore_iio_1
unc_iio_data_req_of_cpu.mem_write.part1 uncore_iio_4
......For the event "unc_iio_data_req_of_cpu.mem_write.part1" with
"uncore_iio_4", it should be the event from PMU "uncore_iio_4".
It's not a new leader for this PMU.But if we use "(leader->pmu_name == evsel->pmu_name)", the check
would be failed and the event is stored to leaders[] as a new
PMU leader.So this patch uses strcmp to compare the PMU name between events.
Fixes: d4953f7ef1a2 ("perf parse-events: Fix 3 use after frees found with clang ASAN")
Signed-off-by: Jin Yao
Acked-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: Jin Yao
Cc: Kan Liang
Cc: Peter Zijlstra
Link: http://lore.kernel.org/lkml/20200430003618.17002-1-yao.jin@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit 463538a383a27337cb83ae195e432a839a52d639 ]
Commit 5aa98879efe7 ("s390/cpum_sf: prohibit callchain data collection")
prohibits call graph sampling for hardware events on s390. The
information recorded is out of context and does not match.On s390 this commit now breaks test case 68 Zstd perf.data
compression/decompression.Therefore omit call graph sampling on s390 in this test.
Output before:
[root@t35lp46 perf]# ./perf test -Fv 68
68: Zstd perf.data compression/decompression :
--- start ---
Collecting compressed record file:
Error:
cycles: PMU Hardware doesn't support sampling/overflow-interrupts.
Try 'perf stat'
---- end ----
Zstd perf.data compression/decompression: FAILED!
[root@t35lp46 perf]#Output after:
[root@t35lp46 perf]# ./perf test -Fv 68
68: Zstd perf.data compression/decompression :
--- start ---
Collecting compressed record file:
500+0 records in
500+0 records out
256000 bytes (256 kB, 250 KiB) copied, 0.00615638 s, 41.6 MB/s
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.004 MB /tmp/perf.data.X3M,
compressed (original 0.002 MB, ratio is 3.609) ]
Checking compressed events stats:
# compressed : Zstd, level = 1, ratio = 4
COMPRESSED events: 1
2ELIFREPh---- end ----
Zstd perf.data compression/decompression: Ok
[root@t35lp46 perf]#Signed-off-by: Thomas Richter
Reviewed-by: Sumanth Korikkar
Cc: Heiko Carstens
Cc: Sven Schnelle
Cc: Vasily Gorbik
Link: http://lore.kernel.org/lkml/20200729135314.91281-1-tmricht@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit a61fa2799ef9bf6c4f54cf7295036577cececc72 ]
Clear the weird flags before logging to improve strace output --
logging results while, say, TF is set does no one any favors.Signed-off-by: Andy Lutomirski
Signed-off-by: Thomas Gleixner
Link: https://lkml.kernel.org/r/907bfa5a42d4475b8245e18b67a04b13ca51ffdb.1593191971.git.luto@kernel.org
Signed-off-by: Sasha Levin -
[ Upstream commit 61f82e3fb697a8e85f22fdec786528af73dc36d1 ]
In the absence of any modules, no "modules" map is created, but there
are other executable pages to map, due to eBPF JIT, kprobe or ftrace.
Map them by recognizing that the first "module" symbol is not
necessarily from a module, and adjust the map accordingly.Signed-off-by: Adrian Hunter
Cc: Alexander Shishkin
Cc: Borislav Petkov
Cc: H. Peter Anvin
Cc: Jiri Olsa
Cc: Leo Yan
Cc: Mark Rutland
Cc: Masami Hiramatsu
Cc: Mathieu Poirier
Cc: Peter Zijlstra
Cc: Steven Rostedt (VMware)
Cc: x86@kernel.org
Link: http://lore.kernel.org/lkml/20200512121922.8997-10-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit a159e2fe89b4d1f9fb54b0ae418b961e239bf617 ]
Avoid a simple memory leak.
Signed-off-by: Ian Rogers
Cc: Alexander Shishkin
Cc: Alexei Starovoitov
Cc: Andi Kleen
Cc: Andrii Nakryiko
Cc: Cong Wang
Cc: Daniel Borkmann
Cc: Jin Yao
Cc: Jiri Olsa
Cc: John Fastabend
Cc: John Garry
Cc: Kajol Jain
Cc: Kan Liang
Cc: Kim Phillips
Cc: Mark Rutland
Cc: Martin KaFai Lau
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Song Liu
Cc: Stephane Eranian
Cc: Vince Weaver
Cc: Yonghong Song
Cc: bpf@vger.kernel.org
Cc: kp singh
Cc: netdev@vger.kernel.org
Link: http://lore.kernel.org/lkml/20200508053629.210324-10-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit 07e9a6f538cbeecaf5c55b6f2991416f873cdcbd ]
Need to free "str" before return when asprintf() failed to avoid memory
leak.Signed-off-by: Xie XiuQi
Cc: Alexander Shishkin
Cc: Hongbo Yao
Cc: Jiri Olsa
Cc: Li Bin
Cc: Mark Rutland
Cc: Namhyung Kim
Link: http://lore.kernel.org/lkml/20200521133218.30150-4-liwei391@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit ea9eb1f456a08c18feb485894185f7a4e31cc8a4 ]
Joakim reported wrong duration_time value for interval bigger
than 4000 [1].The problem is in the interval value we pass to update_stats
function, which is typed as 'unsigned int' and overflows when
we get over 2^32 (happens between intervals 4000 and 5000).Retyping the passed value to unsigned long long.
[1] https://www.spinics.net/lists/linux-perf-users/msg11777.html
Fixes: b90f1333ef08 ("perf stat: Update walltime_nsecs_stats in interval mode")
Reported-by: Joakim Zhang
Signed-off-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lore.kernel.org/lkml/20200518131445.3745083-1-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit 7597ce89b3ed239f7a3408b930d2a6c7a4c938a1 ]
Make the architecture test directory agree with the code comment.
Committer notes:
This was split from a larger patch.
The code was assuming the developer always worked from tools/perf/, so make sure we
do the test -d having $toolsdir/perf/arch/$arch, to match the intent expressed in the comment,
just above that loop.Signed-off-by: Ian Rogers
Cc: Adrian Hunter
Cc: Alexander Shishkin
Cc: Alexios Zavras
Cc: Andi Kleen
Cc: Greg Kroah-Hartman
Cc: Igor Lubashev
Cc: Jiri Olsa
Cc: Kan Liang
Cc: Mark Rutland
Cc: Mathieu Poirier
Cc: Namhyung Kim
Cc: Nick Desaulniers
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Thomas Gleixner
Cc: Wei Li
Link: http://lore.kernel.org/lkml/20200306071110.130202-4-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit 3efc899d9afb3d03604f191a0be9669eabbfc4aa ]
If allocated, perf_pkg_mask and metric_events need freeing.
Signed-off-by: Ian Rogers
Reviewed-by: Andi Kleen
Cc: Adrian Hunter
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lore.kernel.org/lkml/20200512235918.10732-1-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit 266150c94c69429cf6d18e130237224a047f5061 ]
Realloc of size zero is a free not an error, avoid this causing a double
free. Caught by clang's address sanitizer:==2634==ERROR: AddressSanitizer: attempting double-free on 0x6020000015f0 in thread T0:
#0 0x5649659297fd in free llvm/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:123:3
#1 0x5649659e9251 in __zfree tools/lib/zalloc.c:13:2
#2 0x564965c0f92c in mem2node__exit tools/perf/util/mem2node.c:114:2
#3 0x564965a08b4c in perf_c2c__report tools/perf/builtin-c2c.c:2867:2
#4 0x564965a0616a in cmd_c2c tools/perf/builtin-c2c.c:2989:10
#5 0x564965944348 in run_builtin tools/perf/perf.c:312:11
#6 0x564965943235 in handle_internal_command tools/perf/perf.c:364:8
#7 0x5649659440c4 in run_argv tools/perf/perf.c:408:2
#8 0x564965942e41 in main tools/perf/perf.c:538:30x6020000015f0 is located 0 bytes inside of 1-byte region [0x6020000015f0,0x6020000015f1)
freed by thread T0 here:
#0 0x564965929da3 in realloc third_party/llvm/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
#1 0x564965c0f55e in mem2node__init tools/perf/util/mem2node.c:97:16
#2 0x564965a08956 in perf_c2c__report tools/perf/builtin-c2c.c:2803:8
#3 0x564965a0616a in cmd_c2c tools/perf/builtin-c2c.c:2989:10
#4 0x564965944348 in run_builtin tools/perf/perf.c:312:11
#5 0x564965943235 in handle_internal_command tools/perf/perf.c:364:8
#6 0x5649659440c4 in run_argv tools/perf/perf.c:408:2
#7 0x564965942e41 in main tools/perf/perf.c:538:3previously allocated by thread T0 here:
#0 0x564965929c42 in calloc third_party/llvm/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3
#1 0x5649659e9220 in zalloc tools/lib/zalloc.c:8:9
#2 0x564965c0f32d in mem2node__init tools/perf/util/mem2node.c:61:12
#3 0x564965a08956 in perf_c2c__report tools/perf/builtin-c2c.c:2803:8
#4 0x564965a0616a in cmd_c2c tools/perf/builtin-c2c.c:2989:10
#5 0x564965944348 in run_builtin tools/perf/perf.c:312:11
#6 0x564965943235 in handle_internal_command tools/perf/perf.c:364:8
#7 0x5649659440c4 in run_argv tools/perf/perf.c:408:2
#8 0x564965942e41 in main tools/perf/perf.c:538:3v2: add a WARN_ON_ONCE when the free condition arises.
Signed-off-by: Ian Rogers
Acked-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Mark Rutland
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: clang-built-linux@googlegroups.com
Link: http://lore.kernel.org/lkml/20200320182347.87675-1-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit bec49a9e05db3dbdca696fa07c62c52638fb6371 ]
When it is not possible for a non-privilege perf command to monitor at
the kernel level (:k), the fallback code forces a :u. That works if the
event was previously monitoring both levels. But if the event was
already constrained to kernel only, then it does not make sense to
restrict it to user only.Given the code works by exclusion, a kernel only event would have:
attr->exclude_user = 1
The fallback code would add:
attr->exclude_kernel = 1
In the end the end would not monitor in either the user level or kernel
level. In other words, it would count nothing.An event programmed to monitor kernel only cannot be switched to user
only without seriously warning the user.This patch forces an error in this case to make it clear the request
cannot really be satisfied.Behavior with paranoid 1:
$ sudo bash -c "echo 1 > /proc/sys/kernel/perf_event_paranoid"
$ perf stat -e cycles:k sleep 1Performance counter stats for 'sleep 1':
1,520,413 cycles:k
1.002361664 seconds time elapsed
0.002480000 seconds user
0.000000000 seconds sysOld behavior with paranoid 2:
$ sudo bash -c "echo 2 > /proc/sys/kernel/perf_event_paranoid"
$ perf stat -e cycles:k sleep 1
Performance counter stats for 'sleep 1':0 cycles:ku
1.002358127 seconds time elapsed
0.002384000 seconds user
0.000000000 seconds sysNew behavior with paranoid 2:
$ sudo bash -c "echo 2 > /proc/sys/kernel/perf_event_paranoid"
$ perf stat -e cycles:k sleep 1
Error:
You may not have permission to collect stats.Consider tweaking /proc/sys/kernel/perf_event_paranoid,
which controls use of the performance events system by
unprivileged users (without CAP_PERFMON or CAP_SYS_ADMIN).The current value is 2:
-1: Allow use of (almost) all events by all users
Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK
>= 0: Disallow ftrace function tracepoint by users without CAP_PERFMON or CAP_SYS_ADMIN
Disallow raw tracepoint access by users without CAP_SYS_PERFMON or CAP_SYS_ADMIN
>= 1: Disallow CPU event access by users without CAP_PERFMON or CAP_SYS_ADMIN
>= 2: Disallow kernel profiling by users without CAP_PERFMON or CAP_SYS_ADMINTo make this setting permanent, edit /etc/sysctl.conf too, e.g.:
kernel.perf_event_paranoid = -1
v2 of this patch addresses the review feedback from jolsa@redhat.com.
Signed-off-by: Stephane Eranian
Reviewed-by: Ian Rogers
Acked-by: Jiri Olsa
Tested-by: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lore.kernel.org/lkml/20200414161550.225588-1-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit 2de4e82318c7f9d34f4b08599a612cd4cd10bf0b ]
This adds test cases for ptrace deadlocks.
Additionally fixes a compile problem in get_syscall_info.c,
observed with gcc-4.8.4:get_syscall_info.c: In function 'get_syscall_info':
get_syscall_info.c:93:3: error: 'for' loop initial declarations are only
allowed in C99 mode
for (unsigned int i = 0; i < ARRAY_SIZE(args); ++i) {
^
get_syscall_info.c:93:3: note: use option -std=c99 or -std=gnu99 to compile
your codeSigned-off-by: Bernd Edlinger
Reviewed-by: Kees Cook
Signed-off-by: Eric W. Biederman
Signed-off-by: Sasha Levin -
[ Upstream commit d1ee7e1f5c9191afb69ce46cc7752e4257340a31 ]
If '-o' was used more than 64 times in a single invocation of gpio-hammer,
this could lead to an overflow of the 'lines' array. This commit fixes
this by avoiding the overflow and giving a proper diagnostic back to the
userSigned-off-by: Gabriel Ravier
Signed-off-by: Bartosz Golaszewski
Signed-off-by: Sasha Levin -
[ Upstream commit d74b181a028bb5a468f0c609553eff6a8fdf4887 ]
'snprintf' returns the number of characters which would be generated for
the given input.If the returned value is *greater than* or equal to the buffer size, it
means that the output has been truncated.Fix the overflow test accordingly.
Fixes: 7780c25bae59f ("perf tools: Allow ability to map cpus to nodes easily")
Fixes: 92a7e1278005b ("perf cpumap: Add cpu__max_present_cpu()")
Signed-off-by: Christophe JAILLET
Suggested-by: David Laight
Cc: Alexander Shishkin
Cc: Don Zickus
Cc: He Zhe
Cc: Jan Stancek
Cc: Jiri Olsa
Cc: Kan Liang
Cc: Mark Rutland
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: kernel-janitors@vger.kernel.org
Link: http://lore.kernel.org/lkml/20200324070319.10901-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit d4953f7ef1a2e87ef732823af35361404d13fea8 ]
Reproducible with a clang asan build and then running perf test in
particular 'Parse event definition strings'.Signed-off-by: Ian Rogers
Acked-by: Jiri Olsa
Cc: Adrian Hunter
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: Leo Yan
Cc: Mark Rutland
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: clang-built-linux@googlegroups.com
Link: http://lore.kernel.org/lkml/20200314170356.62914-1-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit c9f5baa136777b2c982f6f7a90c9da69a88be148 ]
When 'etm->instructions_sample_period' is less than
'tidq->period_instructions', the function cs_etm__sample() cannot handle
this case properly with its logic.Let's see below flow as an example:
- If we set itrace option '--itrace=i4', then function cs_etm__sample()
has variables with initialized values:tidq->period_instructions = 0
etm->instructions_sample_period = 4- When the first packet is coming:
packet->instr_count = 10; the number of instructions executed in this
packet is 10, thus update period_instructions as below:tidq->period_instructions = 0 + 10 = 10
instrs_over = 10 - 4 = 6
offset = 10 - 6 - 1 = 3
tidq->period_instructions = instrs_over = 6- When the second packet is coming:
packet->instr_count = 10; in the second pass, assume 10 instructions
in the trace sample again:tidq->period_instructions = 6 + 10 = 16
instrs_over = 16 - 4 = 12
offset = 10 - 12 - 1 = -3 -> the negative value
tidq->period_instructions = instrs_over = 12So after handle these two packets, there have below issues:
The first issue is that cs_etm__instr_addr() returns the address within
the current trace sample of the instruction related to offset, so the
offset is supposed to be always unsigned value. But in fact, function
cs_etm__sample() might calculate a negative offset value (in handling
the second packet, the offset is -3) and pass to cs_etm__instr_addr()
with u64 type with a big positive integer.The second issue is it only synthesizes 2 samples for sample period = 4.
In theory, every packet has 10 instructions so the two packets have
total 20 instructions, 20 instructions should generate 5 samples
(4 x 5 = 20). This is because cs_etm__sample() only calls once
cs_etm__synth_instruction_sample() to generate instruction sample per
range packet.This patch fixes the logic in function cs_etm__sample(); the basic
idea for handling coming packet is:- To synthesize the first instruction sample, it combines the left
instructions from the previous packet and the head of the new
packet; then generate continuous samples with sample period;
- At the tail of the new packet, if it has the rest instructions,
these instructions will be left for the sequential sample.Suggested-by: Mike Leach
Signed-off-by: Leo Yan
Reviewed-by: Mathieu Poirier
Reviewed-by: Mike Leach
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Robert Walker
Cc: Suzuki Poulouse
Cc: coresight ml
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lore.kernel.org/lkml/20200219021811.20067-4-leo.yan@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit d01751563caf0dec7be36f81de77cc0197b77e59 ]
If use option '--itrace=iNNN' with Arm CoreSight trace data, perf tool
fails inject instruction samples; the root cause is the packets are only
swapped for branch samples and last branches but not for instruction
samples, so the new coming packets cannot be properly handled for only
synthesizing instruction samples.To fix this issue, this patch refactors the code with a new function
cs_etm__packet_swap() which is used to swap packets and adds the
condition for instruction samples.Signed-off-by: Leo Yan
Reviewed-by: Mathieu Poirier
Reviewed-by: Mike Leach
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Robert Walker
Cc: Suzuki Poulouse
Cc: coresight ml
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lore.kernel.org/lkml/20200219021811.20067-2-leo.yan@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit 3f5777fbaf04c58d940526a22a2e0c813c837936 ]
The memory for global pointer is never freed during normal program
execution, so let's do that in the main function exit as a good
programming practice.A stray blank line is also removed.
Reported-by: Jiri Olsa
Signed-off-by: John Garry
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: James Clark
Cc: Joakim Zhang
Cc: Mark Rutland
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: linuxarm@huawei.com
Link: http://lore.kernel.org/lkml/1583406486-154841-2-git-send-email-john.garry@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit 2bbc83537614517730e9f2811195004b712de207 ]
This test places a kprobe to function getname_flags() in the kernel
which has the following prototype:struct filename *getname_flags(const char __user *filename, int flags, int *empty)
The 'filename' argument points to a filename located in user space memory.
Looking at commit 88903c464321c ("tracing/probe: Add ustring type for
user-space string") the kprobe should indicate that user space memory is
accessed.Output before:
[root@m35lp76 perf]# ./perf test 66 67
66: Use vfs_getname probe to get syscall args filenames : FAILED!
67: Check open filename arg using perf trace + vfs_getname: FAILED!
[root@m35lp76 perf]#Output after:
[root@m35lp76 perf]# ./perf test 66 67
66: Use vfs_getname probe to get syscall args filenames : Ok
67: Check open filename arg using perf trace + vfs_getname: Ok
[root@m35lp76 perf]#Comments from Masami Hiramatsu:
This bug doesn't happen on x86 or other archs on which user address
space and kernel address space is the same. On some arches (ppc64 in
this case?) user address space is partially or completely the same as
kernel address space.(Yes, they switch the world when running into the kernel) In this case,
we need to use different data access functions for each space.That is why I introduced the "ustring" type for kprobe events.
As far as I can see, Thomas's patch is sane. Thomas, could you show us
your result on your test environment?Comments from Thomas Richter:
Test results for s/390 included above.
Signed-off-by: Thomas Richter
Acked-by: Masami Hiramatsu
Tested-by: Arnaldo Carvalho de Melo
Cc: Heiko Carstens
Cc: Sumanth Korikkar
Cc: Vasily Gorbik
Link: http://lore.kernel.org/lkml/20200217102111.61137-1-tmricht@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit e749e09db30c38f1a275945814b0109e530a07b0 ]
Some syntax needs to be more rigorous for python 3.
Backwards compatibility tested with python 2.7Signed-off-by: Doug Smythies
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin -
[ Upstream commit af4ddd607dff7aabd466a4a878e01b9f592a75ab ]
test.d/ftrace/func-filter-glob.tc is failing on s390 because it has
ARCH_INLINE_SPIN_LOCK and friends set to 'y'. So the usual
__raw_spin_lock symbol isn't in the ftrace function list. Change
'*aw*lock' to '*spin*lock' which would hopefully match some of the
locking functions on all platforms.Reviewed-by: Steven Rostedt (VMware)
Signed-off-by: Sven Schnelle
Signed-off-by: Shuah Khan
Signed-off-by: Sasha Levin -
[ Upstream commit ef8c84effce3c7a0b8196fcda8f430c815ab511c ]
It looks like BPF program that handles BPF_SOCK_OPS_STATE_CB state
can race with the bpf_map_lookup_elem("global_map"); I sometimes
see the failures in this test and re-running helps.Since we know that we expect the callback to be called 3 times (one
time for listener socket, two times for both ends of the connection),
let's export this number and add simple retry logic around that.Also, let's make EXPECT_EQ() not return on failure, but continue
evaluating all conditions; that should make potential debugging
easier.With this fix in place I don't observe the flakiness anymore.
Signed-off-by: Stanislav Fomichev
Signed-off-by: Alexei Starovoitov
Cc: Lawrence Brakmo
Link: https://lore.kernel.org/bpf/20191204190955.170934-1-sdf@google.com
Signed-off-by: Sasha Levin
23 Sep, 2020
6 commits
-
commit 1ec882fc81e3177faf055877310dbdb0c68eb7db upstream.
The displayed size is in bytes while the text says it is in kB.
Shift it by 10 to really display kBytes.
Fixes: fa7b9a805c79 ("tools/selftest/vm: allow choosing mem size and page size in map_hugetlb")
Signed-off-by: Christophe Leroy
Signed-off-by: Andrew Morton
Cc:
Link: https://lkml.kernel.org/r/e27481224564a93d14106e750de31189deaa8bc8.1598861977.git.christophe.leroy@csgroup.eu
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit d26383dcb2b4b8629fde05270b4e3633be9e3d4b ]
The following leaks were detected by ASAN:
Indirect leak of 360 byte(s) in 9 object(s) allocated from:
#0 0x7fecc305180e in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10780e)
#1 0x560578f6dce5 in perf_pmu__new_format util/pmu.c:1333
#2 0x560578f752fc in perf_pmu_parse util/pmu.y:59
#3 0x560578f6a8b7 in perf_pmu__format_parse util/pmu.c:73
#4 0x560578e07045 in test__pmu tests/pmu.c:155
#5 0x560578de109b in run_test tests/builtin-test.c:410
#6 0x560578de109b in test_and_print tests/builtin-test.c:440
#7 0x560578de401a in __cmd_test tests/builtin-test.c:661
#8 0x560578de401a in cmd_test tests/builtin-test.c:807
#9 0x560578e49354 in run_builtin /home/namhyung/project/linux/tools/perf/perf.c:312
#10 0x560578ce71a8 in handle_internal_command /home/namhyung/project/linux/tools/perf/perf.c:364
#11 0x560578ce71a8 in run_argv /home/namhyung/project/linux/tools/perf/perf.c:408
#12 0x560578ce71a8 in main /home/namhyung/project/linux/tools/perf/perf.c:538
#13 0x7fecc2b7acc9 in __libc_start_main ../csu/libc-start.c:308Fixes: cff7f956ec4a1 ("perf tests: Move pmu tests into separate object")
Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: Ian Rogers
Cc: Mark Rutland
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lore.kernel.org/lkml/20200915031819.386559-12-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit b12eea5ad8e77f8a380a141e3db67c07432dde16 ]
The evsel->unit borrows a pointer of pmu event or alias instead of
owns a string. But tool event (duration_time) passes a result of
strdup() caused a leak.It was found by ASAN during metric test:
Direct leak of 210 byte(s) in 70 object(s) allocated from:
#0 0x7fe366fca0b5 in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x920b5)
#1 0x559fbbcc6ea3 in add_event_tool util/parse-events.c:414
#2 0x559fbbcc6ea3 in parse_events_add_tool util/parse-events.c:1414
#3 0x559fbbd8474d in parse_events_parse util/parse-events.y:439
#4 0x559fbbcc95da in parse_events__scanner util/parse-events.c:2096
#5 0x559fbbcc95da in __parse_events util/parse-events.c:2141
#6 0x559fbbc28555 in check_parse_id tests/pmu-events.c:406
#7 0x559fbbc28555 in check_parse_id tests/pmu-events.c:393
#8 0x559fbbc28555 in check_parse_cpu tests/pmu-events.c:415
#9 0x559fbbc28555 in test_parsing tests/pmu-events.c:498
#10 0x559fbbc0109b in run_test tests/builtin-test.c:410
#11 0x559fbbc0109b in test_and_print tests/builtin-test.c:440
#12 0x559fbbc03e69 in __cmd_test tests/builtin-test.c:695
#13 0x559fbbc03e69 in cmd_test tests/builtin-test.c:807
#14 0x559fbbc691f4 in run_builtin /home/namhyung/project/linux/tools/perf/perf.c:312
#15 0x559fbbb071a8 in handle_internal_command /home/namhyung/project/linux/tools/perf/perf.c:364
#16 0x559fbbb071a8 in run_argv /home/namhyung/project/linux/tools/perf/perf.c:408
#17 0x559fbbb071a8 in main /home/namhyung/project/linux/tools/perf/perf.c:538
#18 0x7fe366b68cc9 in __libc_start_main ../csu/libc-start.c:308Fixes: f0fbb114e3025 ("perf stat: Implement duration_time as a proper event")
Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: Ian Rogers
Cc: Mark Rutland
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lore.kernel.org/lkml/20200915031819.386559-6-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit bfd1b83d75e44a9f65de30accb3dd3b5940bd3ac ]
Asan reported leak of cpu and thread maps as they have one more refcount
than released. I found that after setting evlist maps it should release
it's refcount.It seems to be broken from the beginning so I chose the original commit
as the culprit. But not sure how it's applied to stable trees since
there are many changes in the code after that.Fixes: 7e2ed097538c5 ("perf evlist: Store pointer to the cpu and thread maps")
Fixes: 4112eb1899c0e ("perf evlist: Default to syswide target when no thread/cpu maps set")
Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: Ian Rogers
Cc: Mark Rutland
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lore.kernel.org/lkml/20200915031819.386559-4-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit 8a39e8c4d9baf65d88f66d49ac684df381e30055 ]
When compiling with DEBUG=1 on Fedora 32 I'm getting crash for 'perf
test signal':Program received signal SIGSEGV, Segmentation fault.
0x0000000000c68548 in __test_function ()
(gdb) bt
#0 0x0000000000c68548 in __test_function ()
#1 0x00000000004d62e9 in test_function () at tests/bp_signal.c:61
#2 0x00000000004d689a in test__bp_signal (test=0xa8e280 DW_AT_producer : (indirect string, offset: 0x254a): GNU C99 10.2.1 20200723 (Red Hat 10.2.1-1) -mtune=generic -march=x86-64 -ggdb3 -std=gnu99 -fno-omit-frame-pointer -funwind-tables -fstack-protector-all
^^^^^
^^^^^
^^^^^
$Before:
$ perf test signal
20: Breakpoint overflow signal handler : FAILED!
$After:
$ perf test signal
20: Breakpoint overflow signal handler : Ok
$Fixes: 8fd34e1cce18 ("perf test: Improve bp_signal")
Signed-off-by: Jiri Olsa
Tested-by: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Wang Nan
Link: http://lore.kernel.org/lkml/20200911130005.1842138-1-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
The ddr bit width on i.MX8MN evk board is 16 bit, not 32 bit.
Reviewed-by: Fugang Duan
Signed-off-by: Joakim Zhang
17 Sep, 2020
1 commit
-
[ Upstream commit 5c1e4f7e9e49b6925b1fb5c507d2c614f3edb292 ]
The following 4 tests in timers can take longer than the default 45
seconds that added in commit 852c8cbf34d3 ("selftests/kselftest/runner.sh:
Add 45 second timeout per test") to run:
* nsleep-lat - 2m7.350s
* set-timer-lat - 2m0.66s
* inconsistency-check - 1m45.074s
* raw_skew - 2m0.013sThus they will be marked as failed with the current 45s setting:
not ok 3 selftests: timers: nsleep-lat # TIMEOUT
not ok 4 selftests: timers: set-timer-lat # TIMEOUT
not ok 6 selftests: timers: inconsistency-check # TIMEOUT
not ok 7 selftests: timers: raw_skew # TIMEOUTDisable the timeout setting for timers can make these tests finish
properly:
ok 3 selftests: timers: nsleep-lat
ok 4 selftests: timers: set-timer-lat
ok 6 selftests: timers: inconsistency-check
ok 7 selftests: timers: raw_skewhttps://bugs.launchpad.net/bugs/1864626
Fixes: 852c8cbf34d3 ("selftests/kselftest/runner.sh: Add 45 second timeout per test")
Signed-off-by: Po-Hsu Lin
Acked-by: John Stultz
Signed-off-by: Shuah Khan
Signed-off-by: Sasha Levin
10 Sep, 2020
4 commits
-
commit a060c1f12b525ba828f871eff3127dabf8daa1e6 upstream.
The help info of option "--no-bpf-event" is wrongly described as "record
bpf events", correct it.Committer testing:
$ perf record -h bpf
Usage: perf record [] []
or: perf record [] -- []--clang-opt
options passed to clang when compiling BPF scriptlets
--clang-path
clang binary to use for compiling BPF scriptlets
--no-bpf-event do not record bpf events$
Fixes: 71184c6ab7e6 ("perf record: Replace option --bpf-event with --no-bpf-event")
Signed-off-by: Wei Li
Acked-by: Song Liu
Tested-by: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Hanjun Guo
Cc: Jiri Olsa
Cc: Li Bin
Cc: Mark Rutland
Cc: Namhyung Kim
Link: http://lore.kernel.org/lkml/20200819031947.12115-1-liwei391@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit e62458e3940eb3dfb009481850e140fbee183b04 ]
The new string should have enough space for the original string and the
back slashes IMHO.Fixes: fbc2844e84038ce3 ("perf vendor events: Use more flexible pattern matching for CPU identification for mapfile.csv")
Signed-off-by: Namhyung Kim
Reviewed-by: Ian Rogers
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: Jiri Olsa
Cc: John Garry
Cc: Kajol Jain
Cc: Mark Rutland
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: William Cohen
Link: http://lore.kernel.org/lkml/20200903152510.489233-1-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit 39c0a53b114d0317e5c4e76b631f41d133af5cb0 ]
perf_event.h has macros that define the field offsets in the data_src
bitmask in perf records. The SNOOPX and REMOTE offsets were both 37.These are distinct fields, and the bitfield layout in perf_mem_data_src
confirms that SNOOPX should be at offset 38.Committer notes:
This was extracted from a larger patch that also contained kernel
changes.Fixes: 52839e653b5629bd ("perf tools: Add support for printing new mem_info encodings")
Signed-off-by: Al Grant
Reviewed-by: Andi Kleen
Cc: Adrian Hunter
Cc: Ian Rogers
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lore.kernel.org/lkml/9974f2d0-bf7f-518e-d9f7-4520e5ff1bb0@foss.arm.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit fa4505675e093e895b7ec49a76d44f6b5ad9602e ]
When stdout output from the selftests tool 'test_maps' gets redirected
into e.g file or pipe, then the output lines increase a lot (from 21
to 33949 lines). This is caused by the printf that happens before the
fork() call, and there are user-space buffered printf data that seems
to be duplicated into the forked process.To fix this fflush() stdout before the fork loop in __run_parallel().
Fixes: 1a97cf1fe503 ("selftests/bpf: speedup test_maps")
Signed-off-by: Jesper Dangaard Brouer
Signed-off-by: Daniel Borkmann
Link: https://lore.kernel.org/bpf/159842985651.1050885.2154399297503372406.stgit@firesoul
Signed-off-by: Sasha Levin
05 Sep, 2020
1 commit
-
commit e48a73a312ebf19cc3d72aa74985db25c30757c1 upstream.
Event modifiers are not mentioned in the perf record or perf stat
manpages. Add them to orient new users more effectively by pointing
them to the perf list manpage for details.Fixes: 2055fdaf8703 ("perf list: Document precise event sampling for AMD IBS")
Signed-off-by: Kim Phillips
Cc: Adrian Hunter
Cc: Alexander Shishkin
Cc: Alexey Budankov
Cc: Ian Rogers
Cc: Jin Yao
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Namhyung Kim
Cc: Paul Clarke
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Tony Jones
Cc: stable@vger.kernel.org
Link: http://lore.kernel.org/lkml/20200901215853.276234-1-kim.phillips@amd.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman
