talos-obmc-linux/tools, branch dev-4.10

perf annotate s390: Implement jump types for perf annotate

2017-05-20T12:31:00+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:31:00+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:31:00+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:30:57+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:08:28+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

x86/mpx: Re-add MPX to selftests Makefile

2017-05-14T12:08:24+00:00

commit e64d5fbe56259c94df504af8ce804cfc6a022adb upstream. Ingo pointed out that the MPX tests were no longer in the selftests Makefile. It appears that I shot myself in the foot on this one and accidentally removed them when I added the pkeys tests, probably from bungling a merge conflict. Reported-by: Ingo Molnar Signed-off-by: Dave Hansen Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Fixes: 5f23f6d082a9 ("x86/pkeys: Add self-tests") Link: http://lkml.kernel.org/r/20170201225629.C3070852@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

cpupower: Fix turbo frequency reporting for pre-Sandy Bridge cores

2017-05-14T12:08:19+00:00

commit 4cca0457686e4ee1677d69469e4ddfd94d389a80 upstream. The switch that conditionally sets CPUPOWER_CAP_HAS_TURBO_RATIO and CPUPOWER_CAP_IS_SNB flags is missing a break, so all cores get both flags set and an assumed base clock of 100 MHz for turbo values. Reported-by: GSR Tested-by: GSR References: https://bugs.debian.org/859978 Fixes: 8fb2e440b223 (cpupower: Show Intel turbo ratio support via ...) Signed-off-by: Ben Hutchings Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

bpf: improve verifier packet range checks

2017-05-03T15:37:38+00:00

[ Upstream commit b1977682a3858b5584ffea7cfb7bd863f68db18d ] llvm can optimize the 'if (ptr > data_end)' checks to be in the order slightly different than the original C code which will confuse verifier. Like: if (ptr + 16 > data_end) return TC_ACT_SHOT; // may be followed by if (ptr + 14 > data_end) return TC_ACT_SHOT; while llvm can see that 'ptr' is valid for all 16 bytes, the verifier could not. Fix verifier logic to account for such case and add a test. Reported-by: Huapeng Zhou Fixes: 969bf05eb3ce ("bpf: direct packet access") Signed-off-by: Alexei Starovoitov Acked-by: Daniel Borkmann Acked-by: Martin KaFai Lau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

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

2017-04-21T07:32:38+00:00

commit 3c1a427954399fd1bda1ee7e1b356f47b61cee74 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

give up on gcc ilog2() constant optimizations

2017-03-26T11:08:10+00:00

commit 474c90156c8dcc2fa815e6716cc9394d7930cb9c upstream. gcc-7 has an "optimization" pass that completely screws up, and generates the code expansion for the (impossible) case of calling ilog2() with a zero constant, even when the code gcc compiles does not actually have a zero constant. And we try to generate a compile-time error for anybody doing ilog2() on a constant where that doesn't make sense (be it zero or negative). So now gcc7 will fail the build due to our sanity checking, because it created that constant-zero case that didn't actually exist in the source code. There's a whole long discussion on the kernel mailing about how to work around this gcc bug. The gcc people themselevs have discussed their "feature" in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785 but it's all water under the bridge, because while it looked at one point like it would be solved by the time gcc7 was released, that was not to be. So now we have to deal with this compiler braindamage. And the only simple approach seems to be to just delete the code that tries to warn about bad uses of ilog2(). So now "ilog2()" will just return 0 not just for the value 1, but for any non-positive value too. It's not like I can recall anybody having ever actually tried to use this function on any invalid value, but maybe the sanity check just meant that such code never made it out in public. Reported-by: Laura Abbott Cc: John Stultz , Cc: Thomas Gleixner Cc: Ard Biesheuvel Signed-off-by: Linus Torvalds Cc: Jiri Slaby Signed-off-by: Greg Kroah-Hartman