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

perf report: Fix NULL pointer dereference in hists__fprintf_nr_sample_events()

2020-06-30T00:07:54+00:00

[ Upstream commit 11b6e5482e178055ec1f2444b55f2518713809d1 ] The 'evname' variable can be NULL, as it is checked a few lines back, check it before using. Fixes: 9e207ddfa207 ("perf report: Show call graph from reference events") Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/ Signed-off-by: Gaurav Singh Signed-off-by: Sasha Levin

selftests/net: in timestamping, strncpy needs to preserve null byte

2020-06-30T00:07:54+00:00

[ Upstream commit 8027bc0307ce59759b90679fa5d8b22949586d20 ] If user passed an interface option longer than 15 characters, then device.ifr_name and hwtstamp.ifr_name became non-null-terminated strings. The compiler warned about this: timestamping.c:353:2: warning: ‘strncpy’ specified bound 16 equals \ destination size [-Wstringop-truncation] 353 | strncpy(device.ifr_name, interface, sizeof(device.ifr_name)); Fixes: cb9eff097831 ("net: new user space API for time stamping of incoming and outgoing packets") Signed-off-by: Tanner Love Acked-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

perf symbols: Fix debuginfo search for Ubuntu

2020-06-20T08:23:25+00:00

commit 85afd35575a3c1a3a905722dde5ee70b49282e70 upstream. Reportedly, from 19.10 Ubuntu has begun mixing up the location of some debug symbol files, putting files expected to be in /usr/lib/debug/usr/lib into /usr/lib/debug/lib instead. Fix by adding another dso_binary_type. Example on Ubuntu 20.04 Before: $ perf record -e intel_pt//u uname Linux [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.030 MB perf.data ] $ perf script --call-trace | head -5 uname 14003 [005] 15321.764958566: cbr: 42 freq: 4219 MHz (156%) uname 14003 [005] 15321.764958566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) 7f1e71cc4100 uname 14003 [005] 15321.764961566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) 7f1e71cc4df0 uname 14003 [005] 15321.764961900: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) 7f1e71cc4e18 uname 14003 [005] 15321.764963233: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) 7f1e71cc5128 After: $ perf script --call-trace | head -5 uname 14003 [005] 15321.764958566: cbr: 42 freq: 4219 MHz (156%) uname 14003 [005] 15321.764958566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) _start uname 14003 [005] 15321.764961566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) _dl_start uname 14003 [005] 15321.764961900: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) _dl_start uname 14003 [005] 15321.764963233: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) _dl_start Reported-by: Travis Downs Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/20200526155207.9172-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

perf probe: Do not show the skipped events

2020-06-20T08:23:25+00:00

commit f41ebe9defacddeae96a872a33f0f22ced0bfcef upstream. When a probe point is expanded to several places (like inlined) and if some of them are skipped because of blacklisted or __init function, those trace_events has no event name. It must be skipped while showing results. Without this fix, you can see "(null):(null)" on the list, # ./perf probe request_resource reserve_setup is out of .text, skip it. Added new events: (null):(null) (on request_resource) probe:request_resource (on request_resource) You can now use it in all perf tools, such as: perf record -e probe:request_resource -aR sleep 1 # With this fix, it is ignored: # ./perf probe request_resource reserve_setup is out of .text, skip it. Added new events: probe:request_resource (on request_resource) You can now use it in all perf tools, such as: perf record -e probe:request_resource -aR sleep 1 # Fixes: 5a51fcd1f30c ("perf probe: Skip kernel symbols which is out of .text") Signed-off-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Namhyung Kim Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/158763968263.30755.12800484151476026340.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

selftests/ipc: Fix test failure seen after initial test run

2020-05-10T08:26:10+00:00

[ Upstream commit b87080eab4c1377706c113fc9c0157f19ea8fed1 ] After successfully running the IPC msgque test once, subsequent runs result in a test failure: $ sudo ./run_kselftest.sh TAP version 13 1..1 # selftests: ipc: msgque # Failed to get stats for IPC queue with id 0 # Failed to dump queue: -22 # Bail out! # # Pass 0 Fail 0 Xfail 0 Xpass 0 Skip 0 Error 0 not ok 1 selftests: ipc: msgque # exit=1 The dump_queue() function loops through the possible message queue index values using calls to msgctl(kern_id, MSG_STAT, ...) where kern_id represents the index value. The first time the test is ran, the initial index value of 0 is valid and the test is able to complete. The index value of 0 is not valid in subsequent test runs and the loop attempts to try index values of 1, 2, 3, and so on until a valid index value is found that corresponds to the message queue created earlier in the test. The msgctl() syscall returns -1 and sets errno to EINVAL when invalid index values are used. The test failure is caused by incorrectly comparing errno to -EINVAL when cycling through possible index values. Fix invalid test failures on subsequent runs of the msgque test by correctly comparing errno values to a non-negated EINVAL. Fixes: 3a665531a3b7 ("selftests: IPC message queue copy feature test") Signed-off-by: Tyler Hicks Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin

perf tools: Fix perf regs mask generation

2020-05-10T08:26:08+00:00

commit f47822078dece7189cad0a5f472f148e5e916736 upstream. On some architectures (powerpc in particular), the number of registers exceeds what can be represented in an integer bitmask. Ensure we generate the proper bitmask on such platforms. Fixes: 71ad0f5e4 ("perf tools: Support for DWARF CFI unwinding on post processing") Signed-off-by: Naveen N. Rao Acked-by: Arnaldo Carvalho de Melo Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman

perf hists: Fix HISTC_MEM_DCACHELINE width setting

2020-05-05T17:13:24+00:00

commit 0805909f59e02036a4e2660159f27dbf8b6084ac upstream. Set correct width for unresolved mem_dcacheline addr. Signed-off-by: Jiri Olsa Cc: David Ahern Cc: Don Zickus Cc: Namhyung Kim Cc: Peter Zijlstra Fixes: 9b32ba71ba90 ("perf tools: Add dcacheline sort") Link: http://lkml.kernel.org/r/1453290995-18485-3-git-send-email-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

selftests/x86/ptrace_syscall_32: Fix no-vDSO segfault

2020-04-24T05:57:06+00:00

[ Upstream commit 630b99ab60aa972052a4202a1ff96c7e45eb0054 ] If AT_SYSINFO is not present, don't try to call a NULL pointer. Reported-by: kbuild test robot Signed-off-by: Andy Lutomirski Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/faaf688265a7e1a5b944d6f8bc0f6368158306d3.1584052409.git.luto@kernel.org Signed-off-by: Sasha Levin

perf map: Fix off by one in strncpy() size argument

2020-04-02T17:02:40+00:00

commit db2c549407d4a76563c579e4768f7d6d32afefba upstream. This patch fixes an off-by-one error in strncpy size argument in tools/perf/util/map.c. The issue is that in: strncmp(filename, "/system/lib/", 11) the passed string literal: "/system/lib/" has 12 bytes (without the NULL byte) and the passed size argument is 11. As a result, the logic won't match the ending "/" byte and will pass filepaths that are stored in other directories e.g. "/system/libmalicious/bin" or just "/system/libmalicious". This functionality seems to be present only on Android. I assume the /system/ directory is only writable by the root user, so I don't think this bug has much (or any) security impact. Fixes: eca818369996 ("perf tools: Add automatic remapping of Android libraries") Signed-off-by: disconnect3d Cc: Alexander Shishkin Cc: Changbin Du Cc: Jiri Olsa Cc: John Keeping Cc: Mark Rutland Cc: Michael Lentine Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Song Liu Cc: Stephane Eranian Link: http://lore.kernel.org/lkml/20200309104855.3775-1-dominik.b.czarnota@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

tools: Let O= makes handle a relative path with -C option

2020-04-02T17:02:37+00:00

[ Upstream commit be40920fbf1003c38ccdc02b571e01a75d890c82 ] When I tried to compile tools/perf from the top directory with the -C option, the O= option didn't work correctly if I passed a relative path: $ make O=BUILD -C tools/perf/ make: Entering directory '/home/mhiramat/ksrc/linux/tools/perf' BUILD: Doing 'make -j8' parallel build ../scripts/Makefile.include:4: *** O=/home/mhiramat/ksrc/linux/tools/perf/BUILD does not exist. Stop. make: *** [Makefile:70: all] Error 2 make: Leaving directory '/home/mhiramat/ksrc/linux/tools/perf' The O= directory existence check failed because the check script ran in the build target directory instead of the directory where I ran the make command. To fix that, once change directory to $(PWD) and check O= directory, since the PWD is set to where the make command runs. Fixes: c883122acc0d ("perf tools: Let O= makes handle relative paths") Reported-by: Randy Dunlap Signed-off-by: Masami Hiramatsu Cc: Andrew Morton Cc: Borislav Petkov Cc: Geert Uytterhoeven Cc: Jiri Olsa Cc: Masahiro Yamada Cc: Michal Marek Cc: Peter Zijlstra Cc: Sasha Levin Cc: Steven Rostedt (VMware) Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/158351957799.3363.15269768530697526765.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin