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

perf annotate s390: Implement jump types for perf annotate

2017-05-20T12:49:45+00:00

commit d9f8dfa9baf9b6ae1f2f84f887176558ecde5268 upstream. Implement simple detection for all kind of jumps and branches. Signed-off-by: Christian Borntraeger Cc: Andreas Krebbel Cc: Hendrik Brueckner Cc: Martin Schwidefsky Cc: Peter Zijlstra Cc: linux-s390 Link: http://lkml.kernel.org/r/1491465112-45819-3-git-send-email-borntraeger@de.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

perf annotate s390: Fix perf annotate error -95 (4.10 regression)

2017-05-20T12:49:45+00:00

commit e77852b32d6d4430c68c38aaf73efe5650fa25af upstream. since 4.10 perf annotate exits on s390 with an "unknown error -95". Turns out that commit 786c1b51844d ("perf annotate: Start supporting cross arch annotation") added a hard requirement for architecture support when objdump is used but only provided x86 and arm support. Meanwhile power was added so lets add s390 as well. While at it make sure to implement the branch and jump types. Signed-off-by: Christian Borntraeger Cc: Andreas Krebbel Cc: Hendrik Brueckner Cc: Martin Schwidefsky Cc: Peter Zijlstra Cc: linux-s390 Fixes: 786c1b51844 "perf annotate: Start supporting cross arch annotation" Link: http://lkml.kernel.org/r/1491465112-45819-2-git-send-email-borntraeger@de.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

perf auxtrace: Fix no_size logic in addr_filter__resolve_kernel_syms()

2017-05-20T12:49:45+00:00

commit c3a0bbc7ad7598dec5a204868bdf8a2b1b51df14 upstream. Address filtering with kernel symbols incorrectly resulted in the error "Cannot determine size of symbol" because the no_size logic was the wrong way around. Signed-off-by: Adrian Hunter Tested-by: Andi Kleen Link: http://lkml.kernel.org/r/1490357752-27942-1-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

selftests/x86/ldt_gdt_32: Work around a glibc sigaction() bug

2017-05-20T12:49:42+00:00

commit 65973dd3fd31151823f4b8c289eebbb3fb7e6bc0 upstream. i386 glibc is buggy and calls the sigaction syscall incorrectly. This is asymptomatic for normal programs, but it blows up on programs that do evil things with segmentation. The ldt_gdt self-test is an example of such an evil program. This doesn't appear to be a regression -- I think I just got lucky with the uninitialized memory that glibc threw at the kernel when I wrote the test. This hackish fix manually issues sigaction(2) syscalls to undo the damage. Without the fix, ldt_gdt_32 segfaults; with the fix, it passes for me. See: https://sourceware.org/bugzilla/show_bug.cgi?id=21269 Signed-off-by: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Juergen Gross Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Garnier Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/aaab0f9f93c9af25396f01232608c163a760a668.1490218061.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

bpf: enhance verifier to understand stack pointer arithmetic

2017-05-14T12:06:01+00:00

[ Upstream commit 332270fdc8b6fba07d059a9ad44df9e1a2ad4529 ] llvm 4.0 and above generates the code like below: .... 440: (b7) r1 = 15 441: (05) goto pc+73 515: (79) r6 = *(u64 *)(r10 -152) 516: (bf) r7 = r10 517: (07) r7 += -112 518: (bf) r2 = r7 519: (0f) r2 += r1 520: (71) r1 = *(u8 *)(r8 +0) 521: (73) *(u8 *)(r2 +45) = r1 .... and the verifier complains "R2 invalid mem access 'inv'" for insn #521. This is because verifier marks register r2 as unknown value after #519 where r2 is a stack pointer and r1 holds a constant value. Teach verifier to recognize "stack_ptr + imm" and "stack_ptr + reg with const val" as valid stack_ptr with new offset. Signed-off-by: Yonghong Song Acked-by: Martin KaFai Lau Acked-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

bpf: Fix values type used in test_maps

2017-04-21T19:16:46+00:00

Maps of per-cpu type have their value element size adjusted to 8 if it is specified smaller during various map operations. This makes test_maps as a 32-bit binary fail, in fact the kernel writes past the end of the value's array on the user's stack. To be quite honest, I think the kernel should reject creation of a per-cpu map that doesn't have a value size of at least 8 if that's what the kernel is going to silently adjust to later. If the user passed something smaller, it is a sizeof() calcualtion based upon the type they will actually use (just like in this testcase code) in later calls to the map operations. Fixes: df570f577231 ("samples/bpf: unit test for BPF_MAP_TYPE_PERCPU_ARRAY") Signed-off-by: David S. Miller Acked-by: Daniel Borkmann Acked-by: Alexei Starovoitov

selftests/net: Fixes psock_fanout CBPF test case

2017-04-20T19:39:19+00:00

'psock_fanout' has been failing since commit 4d7b9dc1f36a9 ("tools: psock_lib: harden socket filter used by psock tests"). That commit changed the CBPF filter to examine the full ethernet frame, and was tested on 'psock_tpacket' which uses SOCK_RAW. But 'psock_fanout' was also using this same CBPF in two places, for filtering and fanout, on a SOCK_DGRAM socket. Change 'psock_fanout' to use SOCK_RAW so that the CBPF program used with SO_ATTACH_FILTER can examine the entire frame. Create a new CBPF program for use with PACKET_FANOUT_DATA which ignores the header, as it cannot see the ethernet header. Tested: Ran tools/testing/selftests/net/psock_{fanout,tpacket} 10 times, and they all passed. Fixes: 4d7b9dc1f36a9 ("tools: psock_lib: harden socket filter used by psock tests") Signed-off-by: 'Mike Maloney ' Signed-off-by: David S. Miller

Merge tag 'trace-v4.11-rc5-4' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace

2017-04-18T17:19:47+00:00

Pull ftrace testcase update from Steven Rostedt: "While testing my development branch, without the fix for the pid use after free bug, the selftest that Namhyung added triggers it. I figured it would be good to add the test for the bug after the fix, such that it does not exist without the fix. I added another patch that lets the test only test part of the pid filtering, and ignores the function-fork (filtering on children as well) if the function-fork feature does not exist. This feature is added by Namhyung just before he added this test. But since the test tests both with and without the feature, it would be good to let it not fail if the feature does not exist" * tag 'trace-v4.11-rc5-4' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: selftests: ftrace: Add check for function-fork before running pid filter test selftests: ftrace: Add a testcase for function PID filter

selftests: ftrace: Add check for function-fork before running pid filter test

2017-04-18T16:46:11+00:00

Have the func-filter-pid test check for the function-fork option before testing it. It can still test the pid filtering, but will stop before testing the function-fork option for children inheriting the pids. This allows the test to be added before the function-fork feature, but after a bug fix that triggers one of the bugs the test can cause. Cc: Namhyung Kim Cc: Shuah Khan Signed-off-by: Steven Rostedt (VMware)

selftests: ftrace: Add a testcase for function PID filter

2017-04-18T16:02:36+00:00

Like event pid filtering test, add function pid filtering test with the new "function-fork" option. It also tests it on an instance directory so that it can verify the bug related pid filtering on instances. Link: http://lkml.kernel.org/r/20170417024430.21194-5-namhyung@kernel.org Cc: Ingo Molnar Cc: Masami Hiramatsu Cc: Shuah Khan Signed-off-by: Namhyung Kim Signed-off-by: Steven Rostedt (VMware)