linux/tools, branch v4.11

bpf: Fix values type used in test_maps

2017-04-21T19:16:46Z

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:19Z

'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:47Z

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:11Z

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:36Z

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)

Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2017-04-14T23:58:38Z

Pull perf fixes from Thomas Gleixner: "Two small fixes for perf: - the move to support cross arch annotation introduced per arch initialization requirements, fullfill them for s/390 (Christian Borntraeger) - add the missing initialization to the LBR entries to avoid exposing random or stale data" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86: Avoid exposing wrong/stale data in intel_pmu_lbr_read_32() perf annotate s390: Fix perf annotate error -95 (4.10 regression)

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

2017-04-13T12:51:10Z

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

Merge branch 'turbostat' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux

2017-04-13T12:50:11Z

Pull turbostat utility fixes for v4.11 from Len Brown. * 'turbostat' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux: tools/power turbostat: update version number tools/power turbostat: fix impossibly large CPU%c1 value tools/power turbostat: turbostat.8 add missing column definitions tools/power turbostat: update HWP dump to decimal from hex tools/power turbostat: enable package THERM_INTERRUPT dump tools/power turbostat: show missing Core and GFX power on SKL and KBL tools/power turbostat: bugfix: GFXMHz column not changing

tools/power turbostat: update version number

2017-04-13T00:03:50Z

Signed-off-by: Len Brown

tools/power turbostat: fix impossibly large CPU%c1 value

2017-04-13T00:03:50Z

Most CPUs do not have a hardware c1 counter, and so turbostat derives c1 residency: c1 = TSC - MPERF - other_core_cstate_counters As it is not possible to atomically read these coutners, measurement jitter can case this calcuation to "go negative" when very close to 0. Turbostat detect that case and simply prints c1 = 0.00% But that check neglected to account for systems where the TSC crystal clock domain and the MPERF BCLK domain are differ by a small amount. That allowed very small negative c1 numbers to escape this check and be printed as huge positve numbers. This code begs for a bit of cleanup, but this patch is the minimal change to fix the issue. Signed-off-by: Len Brown