kernel/linux.git/tools, branch v4.20.12

tools uapi: fix Alpha support

2019-02-20T09:29:11+00:00

commit 842fc0f5dc5c9f9bd91f891554996d903c40cf35 upstream. Cc: stable@vger.kernel.org # v4.18+ Signed-off-by: Bob Tracy Signed-off-by: Matt Turner Signed-off-by: Greg Kroah-Hartman

tools uapi: fix RISC-V 64-bit support

2019-02-20T09:29:02+00:00

[ Upstream commit d0df00e30e4bf9bc27ddbd092ad683ff6121b360 ] The BPF library is not built on 64-bit RISC-V, as the BPF feature is not detected. Looking more in details, feature/test-bpf.c fails to build with the following error: | In file included from /tmp/linux-4.19.12/tools/include/uapi/asm/bitsperlong.h:17, | from /tmp/linux-4.19.12/tools/include/uapi/asm-generic/unistd.h:2, | from /usr/include/riscv64-linux-gnu/asm/unistd.h:1, | from test-bpf.c:2: | /tmp/linux-4.19.12/tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent word size. Check asm/bitsperlong.h | #error Inconsistent word size. Check asm/bitsperlong.h | ^~~~~ The UAPI from the tools directory is missing RISC-V support, therefore bitsperlong.h from asm-generic is used, defaulting to 32 bits. Fix that by adding tools/arch/riscv/include/uapi/asm/bitsperlong.h as a copy of arch/riscv/include/uapi/asm/bitsperlong.h and by updating tools/include/uapi/asm/bitsperlong.h. Signed-off-by: Aurelien Jarno Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin

perf test shell: Use a fallback to get the pathname in vfs_getname

2019-02-20T09:29:01+00:00

[ Upstream commit 03fa483821c0b4db7c2b1453d3332f397d82313f ] Some kernels, like 4.19.13-300.fc29.x86_64 in fedora 29, fail with the existing probe definition asking for the contents of result->name, working when we ask for the 'filename' variable instead, so add a fallback to that. Now those tests are back working on fedora 29 systems with that kernel: # perf test vfs_getname 65: Use vfs_getname probe to get syscall args filenames : Ok 66: Add vfs_getname probe to get syscall args filenames : Ok 67: Check open filename arg using perf trace + vfs_getname: Ok # Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Link: https://lkml.kernel.org/n/tip-klt3n0i58dfqttveti09q3fi@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin

perf report: Fix wrong iteration count in --branch-history

2019-02-20T09:29:01+00:00

[ Upstream commit a3366db06bb656cef2e03f30f780d93059bcc594 ] By calculating the removed loops, we can get the iteration count. But the iteration count could be reported incorrectly, reporting impossibly high counts. That's because previous code uses the number of removed LBR entries for the iteration count. That's not good. Fix this by increasing the iteration count when a loop is detected. When matching the chain, the iteration count would be added up, finally we need to compute the average value when printing out. For example, $ perf report --branch-history --stdio --no-children Before: ---f2 +0 | |--33.62%--f1 +9 (cycles:1) | f1 +0 | main +22 (cycles:1) | main +17 | main +38 (cycles:1) | main +27 | f1 +26 (cycles:1) | f1 +24 | f2 +27 (cycles:7) | f2 +0 | f1 +19 (cycles:1) | f1 +14 | f2 +27 (cycles:11) | f2 +0 | f1 +9 (cycles:1 iter:2968 avg_cycles:3) | f1 +0 | main +22 (cycles:1 iter:2968 avg_cycles:3) | main +17 | main +38 (cycles:1 iter:2968 avg_cycles:3) 2968 is an impossible high iteration count and avg_cycles is too small. After: ---f2 +0 | |--33.62%--f1 +9 (cycles:1) | f1 +0 | main +22 (cycles:1) | main +17 | main +38 (cycles:1) | main +27 | f1 +26 (cycles:1) | f1 +24 | f2 +27 (cycles:7) | f2 +0 | f1 +19 (cycles:1) | f1 +14 | f2 +27 (cycles:11) | f2 +0 | f1 +9 (cycles:1 iter:1 avg_cycles:23) | f1 +0 | main +22 (cycles:1 iter:1 avg_cycles:23) | main +17 | main +38 (cycles:1 iter:1 avg_cycles:23) avg_cycles:23 is the average cycles of this iteration. Fixes: c4ee06251d42 ("perf report: Calculate the average cycles of iterations") Signed-off-by: Jin Yao Cc: Alexander Shishkin Cc: Andi Kleen Cc: Jiri Olsa Cc: Kan Liang Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1546582230-17507-1-git-send-email-yao.jin@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin

perf stat: Fix endless wait for child process

2019-02-20T09:29:01+00:00

[ Upstream commit 8a99255a50c0b4c2a449b96fd8d45fcc8d72c701 ] We hit a 'perf stat' issue by using following script: #!/bin/bash sleep 1000 & exec perf stat -a -e cycles -I1000 -- sleep 5 Since "perf stat" is launched by exec, the "sleep 1000" would be the child process of "perf stat". The wait4() call will not return because it's waiting for the child process "sleep 1000" to end. So 'perf stat' doesn't return even after 5s passes. This patch lets 'perf stat' return when the specified child process ends (in this case, the specified child process is "sleep 5"). Committer testing: # cat test.sh #!/bin/bash sleep 10 & exec perf stat -a -e cycles -I1000 -- sleep 5 # Before: # time ./test.sh # time counts unit events 1.001113090 108,453,351 cycles 2.002062196 142,075,435 cycles 3.002896194 164,801,068 cycles 4.003731666 107,062,140 cycles 5.002068867 112,241,832 cycles real 0m10.066s user 0m0.016s sys 0m0.101s # After: # time ./test.sh # time counts unit events 1.001016096 91,412,027 cycles 2.002014963 124,063,708 cycles 3.002883964 125,993,929 cycles 4.003706470 120,465,734 cycles 5.002006778 163,560,355 cycles real 0m5.123s user 0m0.014s sys 0m0.105s # Signed-off-by: Jin Yao Reviewed-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Andi Kleen Cc: Kan Liang Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1546501245-4512-1-git-send-email-yao.jin@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin

tools: iio: iio_generic_buffer: make num_loops signed

2019-02-15T07:11:03+00:00

commit b119d3bc328e7a9574861ebe0c2110e2776c2de1 upstream. Currently, num_loops is unsigned, but it's set by strtoll, which returns a (signed) long long int. This could lead to overflow, and it also makes the check "num_loops < 0" always be false, since num_loops is unsigned. Setting num_loops to -1 to loop forever is almost working because num_loops is getting set to a very high number, but it's technically still incorrect. Fix this issue by making num_loops signed. This also fixes an error found by Smatch. Signed-off-by: Martin Kelly Reported-by: Dan Carpenter Fixes: 55dda0abcf9d ("tools: iio: iio_generic_buffer: allow continuous looping") Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

perf tests evsel-tp-sched: Fix bitwise operator

2019-02-12T19:02:38+00:00

commit 489338a717a0dfbbd5a3fabccf172b78f0ac9015 upstream. Notice that the use of the bitwise OR operator '|' always leads to true in this particular case, which seems a bit suspicious due to the context in which this expression is being used. Fix this by using bitwise AND operator '&' instead. This bug was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva Acked-by: Jiri Olsa Cc: Alexander Shishkin Cc: Namhyung Kim Cc: Peter Zijlstra Cc: stable@vger.kernel.org Fixes: 6a6cd11d4e57 ("perf test: Add test for the sched tracepoint format fields") Link: http://lkml.kernel.org/r/20190122233439.GA5868@embeddedor Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

perf python: Do not force closing original perf descriptor in evlist.get_pollfd()

2019-02-12T19:02:29+00:00

[ Upstream commit a389aece97938966616ce0336466b98b0351ef10 ] Ondřej reported that when compiled with python3, the python extension regresses in evlist.get_pollfd function behaviour. The evlist.get_pollfd function creates file objects from evlist's fds and returns them in a list. The python3 version also sets them to 'close the original descriptor' when the object dies (is closed), by passing True via the 'closefd' arg in the PyFile_FromFd call. The python's closefd doc says: If closefd is False, the underlying file descriptor will be kept open when the file is closed. That's why the following line in python3 closes all evlist fds: evlist.get_pollfd() the returned list is immediately destroyed and that takes down the original events fds. Passing closefd as False to PyFile_FromFd to fix this. Reported-by: Ondřej Lysoněk Signed-off-by: Jiri Olsa Cc: Alexander Shishkin Cc: Jaroslav Škarvada Cc: Namhyung Kim Cc: Peter Zijlstra Fixes: 66dfdff03d19 ("perf tools: Add Python 3 support") Link: http://lkml.kernel.org/r/20181226112121.5285-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin

perf build: Don't unconditionally link the libbfd feature test to -liberty and -lz

2019-02-12T19:02:27+00:00

[ Upstream commit 14541b1e7e723859ff2c75c6fc10cdbbec6b8c34 ] Current libbfd feature test unconditionally links against -liberty and -lz. While it's required on some systems (e.g. opensuse), it's completely unnecessary on the others, where only -lbdf is sufficient (debian). This patch streamlines (and renames) the following feature checks: feature-libbfd - only link against -lbfd (debian), see commit 2cf9040714f3 ("perf tools: Fix bfd dependency libraries detection") feature-libbfd-liberty - link against -lbfd and -liberty feature-libbfd-liberty-z - link against -lbfd, -liberty and -lz (opensuse), see commit 280e7c48c3b8 ("perf tools: fix BFD detection on opensuse") (feature-liberty{,-z} were renamed to feature-libbfd-liberty{,z} for clarity) The main motivation is to fix this feature test for bpftool which is currently broken on debian (libbfd feature shows OFF, but we still unconditionally link against -lbfd and it works). Tested on debian with only -lbfd installed (without -liberty); I'd appreciate if somebody on the other systems can test this new detection method. Signed-off-by: Stanislav Fomichev Acked-by: Jiri Olsa Cc: Alexander Shishkin Cc: Mathieu Poirier Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/4dfc634cfcfb236883971b5107cf3c28ec8a31be.1542328222.git.sdf@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin

selftests: kvm: report failed stage when exit reason is unexpected

2019-02-12T19:02:27+00:00

[ Upstream commit b85c32dd27495075380350fcd5d614a6b45311b8 ] When we get a report like ==== Test Assertion Failure ==== x86_64/state_test.c:157: run->exit_reason == KVM_EXIT_IO pid=955 tid=955 - Success 1 0x0000000000401350: main at state_test.c:154 2 0x00007fc31c9e9412: ?? ??:0 3 0x000000000040159d: _start at ??:? Unexpected exit reason: 8 (SHUTDOWN), it is not obvious which particular stage failed. Add the info. Signed-off-by: Vitaly Kuznetsov Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin