- 19 Mar, 2018 10 commits
-
-
Ingo Molnar authored
Merge tag 'perf-core-for-mingo-4.17-20180319' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: - Fixes for problems experienced with new GCC 8 warnings, that treated as errors, broke the build, related to snprintf and casting issues. (Arnaldo Carvalho de Melo, Jiri Olsa, Josh Poinboeuf) - Fix build of new breakpoint 'perf test' entry with clang < 6, noticed on fedora 25, 26 and 27 (Arnaldo Carvalho de Melo) - Workaround problem with symbol resolution in 'perf annotate', using the symbol name already present in the objdump output (Arnaldo Carvalho de Melo) - Document 'perf top --ignore-vmlinux' (Arnaldo Carvalho de Melo) - Fix out of bounds access on array fd when cnt is 100 in one of the 'perf test' entries, detected using 'cpptest' (Colin Ian King) - Add support for the forced leader feature, i.e. 'perf report --group' for a group of events not really grouped when scheduled (without using {} to enclose the list of events in the command line) in pipe mode, e.g.: $ perf record -e cycles,instructions -o - kill | perf report --group -i - - Use right type to access array elements in 'perf probe' (Masami Hiramatsu) - Update POWER9 vendor events (those described in JSON format) (Sukadev Bhattiprolu) - Discard head in overwrite_rb_find_range() (Yisheng Xie) - Avoid setting 'quiet' to 'true' unnecessarily (Yisheng Xie) Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org>
-
Ingo Molnar authored
Signed-off-by: Ingo Molnar <mingo@kernel.org>
-
Arnaldo Carvalho de Melo authored
To shut up this compiler warning: CC /tmp/build/perf/tests/bp_account.o CC /tmp/build/perf/tests/task-exit.o CC /tmp/build/perf/tests/sw-clock.o tests/bp_account.c:106:20: error: pointer type mismatch ('int (*)(void)' and 'void *') [-Werror,-Wpointer-type-mismatch] void *addr = is_x ? test_function : (void *) &the_var; ^ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~ 1 error generated. Noticed with clang 6 on fedora rawhide. [perfbuilder@44490f0e7241 perf]$ clang -v clang version 6.0.0 (tags/RELEASE_600/final) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/8 Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/8 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/8 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 [perfbuilder@44490f0e7241 perf]$ Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Fixes: 032db28e ("perf tests: Add breakpoint accounting/modify test") Link: https://lkml.kernel.org/n/tip-a3jnkzh4xam0l954de5tn66d@git.kernel.orgSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Josh Poimboeuf authored
Starting with recent GCC 8 builds, objtool and perf fail to build with the following error: ../str_error_r.c: In function ‘str_error_r’: ../str_error_r.c:25:3: error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict] snprintf(buf, buflen, "INTERNAL ERROR: strerror_r(%d, %p, %zd)=%d", errnum, buf, buflen, err); The code seems harmless, but there's probably no benefit in printing the 'buf' pointer in this situation anyway, so just remove it to make GCC happy. Reported-by: Laura Abbott <labbott@redhat.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Tested-by: Laura Abbott <labbott@redhat.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/r/20180316031154.juk2uncs7baffctp@trebleSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Masami Hiramatsu authored
Current 'perf probe' converts the type of array-elements incorrectly. It always converts the types as a pointer of array. This passes the "array" type DIE to the type converter so that it can get correct "element of array" type DIE from it. E.g. ==== $ cat hello.c #include <stdio.h> void foo(int a[]) { printf("%d\n", a[1]); } void main() { int a[3] = {4, 5, 6}; printf("%d\n", a[0]); foo(a); } $ gcc -g hello.c -o hello $ perf probe -x ./hello -D "foo a[1]" ==== Without this fix, above outputs ==== p:probe_hello/foo /tmp/hello:0x4d3 a=+4(-8(%bp)):u64 ==== The "u64" means "int *", but a[1] is "int". With this, ==== p:probe_hello/foo /tmp/hello:0x4d3 a=+4(-8(%bp)):s32 ==== So, "int" correctly converted to "s32" Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Tom Zanussi <tom.zanussi@linux.intel.com> Cc: linux-kselftest@vger.kernel.org Cc: linux-trace-users@vger.kernel.org Fixes: b2a3c12b ("perf probe: Support tracing an entry of array") Link: http://lkml.kernel.org/r/152129114502.31874.2474068470011496356.stgit@devboxSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Arnaldo Carvalho de Melo authored
There is a bug where when using 'perf annotate timerqueue_add' the target for its only routine called with the 'callq' instruction, 'rb_insert_color', doesn't get resolved from its address when parsing that 'callq' instruction. That symbol resolution works when using 'perf report --tui' and then doing annotation for 'timerqueue_add' from there, the vmlinux dso->symbols rb_tree somehow gets in a state that we can't find that address, that is a bug that has to be further investigated. But since the objdump output has the function name, i.e. the raw objdump disassembled line looks like: So, before: # perf annotate timerqueue_add │ mov %rbx,%rdi │ mov %rbx,(%rdx) │ → callq *ffffffff8184dc80 │ mov 0x8(%rbp),%rdx │ test %rdx,%rdx │ ↓ je 67 # perf report │ mov %rbx,%rdi │ mov %rbx,(%rdx) │ → callq rb_insert_color │ mov 0x8(%rbp),%rdx │ test %rdx,%rdx │ ↓ je 67 And after both look the same: # perf annotate timerqueue_add │ mov %rbx,%rdi │ mov %rbx,(%rdx) │ → callq rb_insert_color │ mov 0x8(%rbp),%rdx │ test %rdx,%rdx │ ↓ je 67 From 'perf report' one can annotate and navigate to that 'rb_insert_color' function, but not directly from 'perf annotate timerqueue_add', that remains to be investigated and fixed. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: https://lkml.kernel.org/n/tip-nkktz6355rhqtq7o8atr8f8r@git.kernel.orgSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Arnaldo Carvalho de Melo authored
We've had this since 2013, document it. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Cc: Willy Tarreau <w@1wt.eu> Fixes: fc2be696 ("perf symbols: Add new option --ignore-vmlinux for perf top") Link: https://lkml.kernel.org/n/tip-0jwfueooddwfsw9r603belxi@git.kernel.orgSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Jiri Olsa authored
The gcc 8 compiler won't compile the python extension code with the following errors (one example): python.c:830:15: error: cast between incompatible function types from \ ‘PyObject * (*)(struct pyrf_evsel *, PyObject *, PyObject *)’ \ uct _object * (*)(struct pyrf_evsel *, struct _object *, struct _object *)’} to \ ‘PyObject * (*)(PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct _objeuct \ _object *)’} [-Werror=cast-function-type] .ml_meth = (PyCFunction)pyrf_evsel__open, The problem with the PyMethodDef::ml_meth callback is that its type is determined based on the PyMethodDef::ml_flags value, which we set as METH_VARARGS | METH_KEYWORDS. That indicates that the callback is expecting an extra PyObject* arg, and is actually PyCFunctionWithKeywords type, but the base PyMethodDef::ml_meth type stays PyCFunction. Previous gccs did not find this, gcc8 now does. Fixing this by silencing this warning for python.c build. Commiter notes: Do not do that for CC=clang, as it breaks the build in some clang versions, like the ones in fedora up to fedora27: fedora:25:error: unknown warning option '-Wno-cast-function-type'; did you mean '-Wno-bad-function-cast'? [-Werror,-Wunknown-warning-option] fedora:26:error: unknown warning option '-Wno-cast-function-type'; did you mean '-Wno-bad-function-cast'? [-Werror,-Wunknown-warning-option] fedora:27:error: unknown warning option '-Wno-cast-function-type'; did you mean '-Wno-bad-function-cast'? [-Werror,-Wunknown-warning-option] # those have: clang version 3.9.1 (tags/RELEASE_391/final) The one in rawhide accepts that: clang version 6.0.0 (tags/RELEASE_600/final) Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Link: http://lkml.kernel.org/r/20180319082902.4518-2-jolsa@kernel.orgSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Jiri Olsa authored
With gcc 8 we get new set of snprintf() warnings that breaks the compilation, one example: tests/mem.c: In function ‘check’: tests/mem.c:19:48: error: ‘%s’ directive output may be truncated writing \ up to 99 bytes into a region of size 89 [-Werror=format-truncation=] snprintf(failure, sizeof failure, "unexpected %s", out); The gcc docs says: To avoid the warning either use a bigger buffer or handle the function's return value which indicates whether or not its output has been truncated. Given that all these warnings are harmless, because the code either properly fails due to uncomplete file path or we don't care for truncated output at all, I'm changing all those snprintf() calls to scnprintf(), which actually 'checks' for the snprint return value so the gcc stays silent. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Link: http://lkml.kernel.org/r/20180319082902.4518-1-jolsa@kernel.orgSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Linus Torvalds authored
-
- 18 Mar, 2018 5 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86/pti updates from Thomas Gleixner: "Another set of melted spectrum updates: - Iron out the last late microcode loading issues by actually checking whether new microcode is present and preventing the CPU synchronization to run into a timeout induced hang. - Remove Skylake C2 from the microcode blacklist according to the latest Intel documentation - Fix the VM86 POPF emulation which traps if VIP is set, but VIF is not. Enhance the selftests to catch that kind of issue - Annotate indirect calls/jumps for objtool on 32bit. This is not a functional issue, but for consistency sake its the right thing to do. - Fix a jump label build warning observed on SPARC64 which uses 32bit storage for the code location which is casted to 64 bit pointer w/o extending it to 64bit first. - Add two new cpufeature bits. Not really an urgent issue, but provides them for both x86 and x86/kvm work. No impact on the current kernel" * 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/microcode: Fix CPU synchronization routine x86/microcode: Attempt late loading only when new microcode is present x86/speculation: Remove Skylake C2 from Speculation Control microcode blacklist jump_label: Fix sparc64 warning x86/speculation, objtool: Annotate indirect calls/jumps for objtool on 32-bit kernels x86/vm86/32: Fix POPF emulation selftests/x86/entry_from_vm86: Add test cases for POPF selftests/x86/entry_from_vm86: Exit with 1 if we fail x86/cpufeatures: Add Intel PCONFIG cpufeature x86/cpufeatures: Add Intel Total Memory Encryption cpufeature
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fix from Thomas Gleixner: "A single fix for vmalloc_fault() which uses p*d_huge() unconditionally whether CONFIG_HUGETLBFS is set or not. In case of CONFIG_HUGETLBFS=n this results in a crash as p*d_huge() returns 0 in that case" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/mm: Fix vmalloc_fault to use pXd_large
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fixes from Thomas Gleixner: "Three fixes for irq chip drivers: - Make sure the allocations in the GIC-V3 ITS driver are large enough to accomodate the interrupt space - Fix a misplaced __iomem annotation which causes a splat of 26 sparse warnings - Remove an unused function in the IMX GPCV2 driver which causes build warnings" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/irq-imx-gpcv2: Remove unused function irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis irqchip/gic-v3-its: Fix misplaced __iomem annotations
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull EFI fix from Thomas Gleixner: "A single fix to prevent partially initialized pointers in mixed mode (64bit kernel on 32bit UEFI)" * 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi/libstub/tpm: Initialize pointer variables to zero for mixed mode
-
git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds authored
Pull KVM fixes from Paolo Bonzini: "PPC: - fix bug leading to lost IPIs and smp_call_function_many() lockups on POWER9 ARM: - locking fix - reset fix - GICv2 multi-source SGI injection fix - GICv2-on-v3 MMIO synchronization fix - make the console less verbose. x86: - fix device passthrough on AMD SME" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: x86: Fix device passthrough when SME is active kvm: arm/arm64: vgic-v3: Tighten synchronization for guests using v2 on v3 KVM: arm/arm64: vgic: Don't populate multiple LRs with the same vintid KVM: arm/arm64: Reduce verbosity of KVM init log KVM: arm/arm64: Reset mapped IRQs on VM reset KVM: arm/arm64: Avoid vcpu_load for other vcpu ioctls than KVM_RUN KVM: arm/arm64: vgic: Add missing irq_lock to vgic_mmio_read_pending KVM: PPC: Book3S HV: Fix trap number return from __kvmppc_vcore_entry
-
- 17 Mar, 2018 1 commit
-
-
John David Anglin authored
Just when I had decided that flush_cache_range() was always called with a valid context, Helge reported two cases where the "BUG_ON(!vma->vm_mm->context);" was hit on the phantom buildd: kernel BUG at /mnt/sdb6/linux/linux-4.15.4/arch/parisc/kernel/cache.c:587! CPU: 1 PID: 3254 Comm: kworker/1:2 Tainted: G D 4.15.0-1-parisc64-smp #1 Debian 4.15.4-1+b1 Workqueue: events free_ioctx IAOQ[0]: flush_cache_range+0x164/0x168 IAOQ[1]: flush_cache_page+0x0/0x1c8 RP(r2): unmap_page_range+0xae8/0xb88 Backtrace: [<00000000404a6980>] unmap_page_range+0xae8/0xb88 [<00000000404a6ae0>] unmap_single_vma+0xc0/0x188 [<00000000404a6cdc>] zap_page_range_single+0x134/0x1f8 [<00000000404a702c>] unmap_mapping_range+0x1cc/0x208 [<0000000040461518>] truncate_pagecache+0x98/0x108 [<0000000040461624>] truncate_setsize+0x9c/0xb8 [<00000000405d7f30>] put_aio_ring_file+0x80/0x100 [<00000000405d803c>] aio_free_ring+0x8c/0x290 [<00000000405d82c0>] free_ioctx+0x80/0x180 [<0000000040284e6c>] process_one_work+0x21c/0x668 [<00000000402854c4>] worker_thread+0x20c/0x778 [<0000000040291d44>] kthread+0x2d4/0x2e0 [<0000000040204020>] end_fault_vector+0x20/0xc0 This indicates that we need to handle the no context case in flush_cache_range() as we do in flush_cache_mm(). In thinking about this, I realized that we don't need to flush the TLB when there is no context. So, I added context checks to the large flush cases in flush_cache_mm() and flush_cache_range(). The large flush case occurs frequently in flush_cache_mm() and the change should improve fork performance. The v2 version of this change removes the BUG_ON from flush_cache_page() by skipping the TLB flush when there is no context. I also added code to flush the TLB in flush_cache_mm() and flush_cache_range() when we have a context that's not current. Now all three routines handle TLB flushes in a similar manner. Signed-off-by: John David Anglin <dave.anglin@bell.net> Cc: stable@vger.kernel.org # 4.9+ Signed-off-by: Helge Deller <deller@gmx.de>
-
- 16 Mar, 2018 24 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linuxLinus Torvalds authored
Pull btrfs fixes from David Sterba: "There's an important revert in this pull request that needs to go to stable as it causes a corruption on big endian machines. The other fix is for FIEMAP incorrectly reporting shared extents before a sync and one fix for a crash in raid56. So far we got only one report about the BE corruption, the stable kernels were out for like a week, so hopefully the scope of the damage is low" * tag 'for-4.16-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: Revert "btrfs: use proper endianness accessors for super_copy" btrfs: add missing initialization in btrfs_check_shared btrfs: Fix NULL pointer exception in find_bio_stripe
-
git://git.monstr.eu/linux-2.6-microblazeLinus Torvalds authored
Pull microblaze fixes from Michal Simek: - Use NO_BOOTMEM to fix boot issue - Fix opt lib endian dependencies * tag 'microblaze-4.16-rc6' of git://git.monstr.eu/linux-2.6-microblaze: microblaze: switch to NO_BOOTMEM microblaze: remove unused alloc_maybe_bootmem microblaze: Setup dependencies for ASM optimized lib functions
-
Borislav Petkov authored
Emanuel reported an issue with a hang during microcode update because my dumb idea to use one atomic synchronization variable for both rendezvous - before and after update - was simply bollocks: microcode: microcode_reload_late: late_cpus: 4 microcode: __reload_late: cpu 2 entered microcode: __reload_late: cpu 1 entered microcode: __reload_late: cpu 3 entered microcode: __reload_late: cpu 0 entered microcode: __reload_late: cpu 1 left microcode: Timeout while waiting for CPUs rendezvous, remaining: 1 CPU1 above would finish, leave and the others will still spin waiting for it to join. So do two synchronization atomics instead, which makes the code a lot more straightforward. Also, since the update is serialized and it also takes quite some time per microcode engine, increase the exit timeout by the number of CPUs on the system. That's ok because the moment all CPUs are done, that timeout will be cut short. Furthermore, panic when some of the CPUs timeout when returning from a microcode update: we can't allow a system with not all cores updated. Also, as an optimization, do not do the exit sync if microcode wasn't updated. Reported-by: Emanuel Czirai <xftroxgpx@protonmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Emanuel Czirai <xftroxgpx@protonmail.com> Tested-by: Ashok Raj <ashok.raj@intel.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lkml.kernel.org/r/20180314183615.17629-2-bp@alien8.de
-
Borislav Petkov authored
Return UCODE_NEW from the scanning functions to denote that new microcode was found and only then attempt the expensive synchronization dance. Reported-by: Emanuel Czirai <xftroxgpx@protonmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Emanuel Czirai <xftroxgpx@protonmail.com> Tested-by: Ashok Raj <ashok.raj@intel.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lkml.kernel.org/r/20180314183615.17629-1-bp@alien8.de
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull drm fixes from Dave Airlie: "i915, amd and nouveau fixes. i915: - backlight fix for some panels - pm fix - fencing fix - some GVT fixes amdgpu: - backlight fix across suspend/resume - object destruction ordering issue fix - displayport fix nouveau: - two backlight fixes - fix for some lockups Pretty quiet week, seems like everyone was fixing backlights" * tag 'drm-fixes-for-v4.16-rc6' of git://people.freedesktop.org/~airlied/linux: drm/nouveau/bl: fix backlight regression drm/nouveau/bl: Fix oops on driver unbind drm/nouveau/mmu: ALIGN_DOWN correct variable drm/i915/gvt: fix user copy warning by whitelist workload rb_tail field drm/i915/gvt: Correct the privilege shadow batch buffer address drm/amdgpu/dce: Don't turn off DP sink when disconnected drm/amdgpu: save/restore backlight level in legacy dce code drm/radeon: fix prime teardown order drm/amdgpu: fix prime teardown order drm/i915: Kick the rps worker when changing the boost frequency drm/i915: Only prune fences after wait-for-all drm/i915: Enable VBT based BL control for DP drm/i915/gvt: keep oa config in shadow ctx drm/i915/gvt: Add runtime_pm_get/put into gvt_switch_mmio
-
Mark Rutland authored
When perf_group_dettach() is called on a group leader, it updates each sibling's group_leader field to point to that sibling, effectively upgrading each siblnig to a group leader. After perf_group_detach has completed, the caller may free the leader event. We only remove siblings from the group leader's sibling_list when the leader has a non-empty group_node. This was fine prior to commit: 8343aae6 ("perf/core: Remove perf_event::group_entry") ... as the sibling's sibling_list would be empty. However, now that we use the sibling_list field as both the list head and the list entry, this leaves each sibling with a non-empty sibling list, including the stale leader event. If perf_group_detach() is subsequently called on a sibling, it will appear to be a group leader, and we'll walk the sibling_list, potentially dereferencing these stale events. In 0day testing, this has been observed to result in kernel panics. Let's avoid this by always removing siblings from the sibling list when we promote them to leaders. Fixes: 8343aae6 ("perf/core: Remove perf_event::group_entry") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: vincent.weaver@maine.edu Cc: Peter Zijlstra <peterz@infradead.org> Cc: torvalds@linux-foundation.org Cc: Alexey Budankov <alexey.budankov@linux.intel.com> Cc: valery.cherepennikov@intel.com Cc: linux-tip-commits@vger.kernel.org Cc: eranian@google.com Cc: acme@redhat.com Cc: alexander.shishkin@linux.intel.com Cc: davidcc@google.com Cc: kan.liang@intel.com Cc: Dmitry.Prohorov@intel.com Cc: Jiri Olsa <jolsa@redhat.com> Link: https://lkml.kernel.org/r/20180316131741.3svgr64yibc6vsid@lakrids.cambridge.arm.com
-
Peter Zijlstra authored
Mark noticed that the change to sibling_list changed some iteration semantics; because previously we used group_list as list entry, sibling events would always have an empty sibling_list. But because we now use sibling_list for both list head and list entry, siblings will report as having siblings. Fix this with a custom for_each_sibling_event() iterator. Fixes: 8343aae6 ("perf/core: Remove perf_event::group_entry") Reported-by: Mark Rutland <mark.rutland@arm.com> Suggested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: vincent.weaver@maine.edu Cc: alexander.shishkin@linux.intel.com Cc: torvalds@linux-foundation.org Cc: alexey.budankov@linux.intel.com Cc: valery.cherepennikov@intel.com Cc: eranian@google.com Cc: acme@redhat.com Cc: linux-tip-commits@vger.kernel.org Cc: davidcc@google.com Cc: kan.liang@intel.com Cc: Dmitry.Prohorov@intel.com Cc: jolsa@redhat.com Link: https://lkml.kernel.org/r/20180315170129.GX4043@hirez.programming.kicks-ass.net
-
Yisheng Xie authored
When using --quiet to disable messages, we will set the 'quiet' variable to 'true' first, then check that variable to decide whether we need to call perf_quiet_option(), so no need to set 'quiet' to 'true' once more in perf_quiet_option(). Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1520944274-37001-2-git-send-email-xieyisheng1@huawei.comSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Yisheng Xie authored
In overwrite mode, start will be set to head in perf_mmap__read_init(). Therefore, there is no need to set the start one more time in overwrite_rb_find_range() and *start can be used as head instead of passing head to overwrite_rb_find_range(). Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com> Reviewed-by: Kan Liang <kan.liang@linux.intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1520944274-37001-1-git-send-email-xieyisheng1@huawei.comSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Sukadev Bhattiprolu authored
Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Link: https://lkml.kernel.org/r/20180313224647.GA22960@us.ibm.comSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Jiri Olsa authored
Stephane reported a problem with forced leader in pipe mode, where report does not force the group output. The reason is that we don't force the leader in pipe mode. This patch adds HEADER_LAST_FEATURE mark to have a point where we have all events and features received, and force the group if requested. $ perf record --group -e '{cycles, instructions}' -o - kill | perf report -i - --group SNIP # Overhead Command Shared Object Symbol # ................ ....... ................ ....................... # 28.36% 0.00% kill libc-2.25.so [.] __unregister_atfork 26.32% 0.00% kill libc-2.25.so [.] _dl_addr 26.10% 0.00% kill ld-2.25.so [.] _dl_relocate_object 17.32% 0.00% kill ld-2.25.so [.] __tunables_init 1.70% 0.01% kill [unknown] [k] 0xffffffffafa01a40 0.20% 0.00% kill ld-2.25.so [.] _start 0.00% 48.77% kill ld-2.25.so [.] do_lookup_x 0.00% 42.97% kill libc-2.25.so [.] _IO_getline 0.00% 6.35% kill ld-2.25.so [.] strcmp 0.00% 1.71% kill ld-2.25.so [.] _dl_sysdep_start 0.00% 0.19% kill ld-2.25.so [.] _dl_start Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Tested-by: Stephane Eranian <eranian@google.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20180314092205.23291-2-jolsa@kernel.orgSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Jiri Olsa authored
We need to synthesize events first, because some features works on top of them (on report side). Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Stephane Eranian <eranian@google.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20180314092205.23291-1-jolsa@kernel.orgSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Colin Ian King authored
Currently when cnt is 100 an array bounds overflow occurs on the assignment of fd[cnt]. Fix this by performing the bounds check on cnt before writing to fd. Detected by cppcheck: tools/perf/tests/bp_account.c:115: (warning) Either the condition 'cnt==100' is redundant or the array 'fd[100]' is accessed at index 100, which is out of bounds. Signed-off-by: Colin King <colin.king@canonical.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: kernel-janitors@vger.kernel.org Fixes: 032db28e ("perf tests: Add breakpoint accounting/modify test") Link: http://lkml.kernel.org/r/20180314173354.11250-1-colin.king@canonical.comSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Arnaldo Carvalho de Melo authored
We were using a local buffer with an arbitrary size, that would have to get increased to avoid truncation as warned by gcc 8: util/annotate.c: In function 'symbol__disassemble': util/annotate.c:1488:4: error: '%s' directive output may be truncated writing up to 4095 bytes into a region of size between 3966 and 8086 [-Werror=format-truncation=] "%s %s%s --start-address=0x%016" PRIx64 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ util/annotate.c:1498:20: symfs_filename, symfs_filename); ~~~~~~~~~~~~~~ util/annotate.c:1490:50: note: format string is defined here " -l -d %s %s -C \"%s\" 2>/dev/null|grep -v \"%s:\"|expand", ^~ In file included from /usr/include/stdio.h:861, from util/color.h:5, from util/sort.h:8, from util/annotate.c:14: /usr/include/bits/stdio2.h:67:10: note: '__builtin___snprintf_chk' output 116 or more bytes (assuming 8331) into a destination of size 8192 return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ __bos (__s), __fmt, __va_arg_pack ()); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ So switch to asprintf, that will make sure enough space is available. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: https://lkml.kernel.org/n/tip-qagoy2dmbjpc9gdnaj0r3mml@git.kernel.orgSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Sandipan Das authored
This fixes record+probe_libc_inet_pton.sh from always exiting with code 0 and making the test pass even if the perf script output does not match the expected pattern. The issue can be observed if this test is run with the verbose flags as shown below: 60: probe libc's inet_pton & backtrace it with ping : ... ping 19602 [006] 16988.413767: probe_libc:inet_pton: (7fff9a2c42e8) 1842e8 __GI___inet_pton (/usr/lib64/libc-2.26.so) 130db4 getaddrinfo (/usr/lib64/libc-2.26.so) FAIL: expected backtrace entry 3 ".*\(.*/bin/ping.*\)$" got "" test child finished with 0 ... probe libc's inet_pton & backtrace it with ping: Ok Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Fixes: e07d585e2454 ("perf tests: Switch trace+probe_libc_inet_pton to use record") Link: http://lkml.kernel.org/r/20180312124450.30371-1-sandipan@linux.vnet.ibm.comSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Jiri Olsa authored
Leo reported broken -k option behavior. The reason is that we used symbol_conf.vmlinux_name as a source for mmap event name, but in fact it's a vmlinux path. Moving the symbol_conf.vmlinux_name check for both host and guest to the proper place and out of the machine__set_mmap_name function. Reported-by: Leo Yan <leo.yan@linaro.org> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Leo Yan <leo.yan@linaro.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Fixes: commit ("8c7f1bb3 perf machine: Move kernel mmap name into struct machine") Link: http://lkml.kernel.org/r/20180312152406.10141-1-jolsa@kernel.orgSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Thomas Richter authored
Function perf_stat_evsel_id_init() has global linkage but is only used in util/stat.c. Make it static. Signed-off-by: Thomas Richter <tmricht@linux.vnet.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Link: http://lkml.kernel.org/r/20180312103807.45069-2-tmricht@linux.vnet.ibm.comSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Jiri Olsa authored
In addition to template, display also the real compile command line with all the variables substituted. llvm compiling command template: $CLANG_EXEC -D__KERNEL__ -D__NR_CPUS__=$NR_CPUS ... llvm compiling command : /usr/bin/clang -D__KERNEL__ -D__NR_CPUS__=24 -DLINUX_VERSION_CODE=0x41000 ... Signed-off-by: Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20180312094313.18738-3-jolsa@kernel.orgSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Yisheng Xie authored
When trying to add the "call-graph" variable for top into the .perfconfig file, like: [top] call-graph = fp I that perf_top_config() do not parse this variable. Fix it by calling perf_default_config() when the top.call-graph variable is set. Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Wang Nan <wangnan0@huawei.com> Fixes: b8cbb349 ("perf config: Bring perf_default_config to the very beginning at main()") Link: http://lkml.kernel.org/r/1520853957-36106-1-git-send-email-xieyisheng1@huawei.comSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Yisheng Xie authored
We have brought perf_default_config to the very beginning at main(), so it no need to call perf_default_config() once more for most of config in perf-record but only for record.call-graph. Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1520853957-36106-2-git-send-email-xieyisheng1@huawei.comSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Martin Vuille authored
Path passed to libdw for unwinding doesn't include symfs path if specified, so unwinding fails because ELF file is not found. Similar to unwinding with libunwind, pass symsrc_filename instead of long_name. If there is no symsrc_filename, fallback to long_name. Signed-off-by: Martin Vuille <jpmv27@aim.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/r/20180211212420.18388-1-jpmv27@aim.comSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Ganapatrao Kulkarni authored
There is MIDR change on ThunderX2 B0, adding an entry to mapfile to enable JSON events for B0. Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com> Acked-by: Will Deacon <will.deacon@arm.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ganapatrao Kulkarni <gpkulkarni@gklkml16.com> Cc: Jayachandran C <jnair@caviumnetworks.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: John Garry <john.garry@huawei.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Robert Richter <robert.richter@cavium.com> Cc: William Cohen <wcohen@redhat.com> Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/20180307110803.32418-1-ganapatrao.kulkarni@cavium.com [ Fixup wrt recent patchset by John Garry ] Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Ingo Molnar authored
When recently using 'perf report --stat' it was not clear to me from the output whether a particular statistics field (LOST_SAMPLES) was not present, or just zero: fomalhaut:~> perf report --stat Aggregated stats: TOTAL events: 495984 MMAP events: 85 COMM events: 3389 EXIT events: 1605 THROTTLE events: 2 UNTHROTTLE events: 2 FORK events: 3377 SAMPLE events: 472629 MMAP2 events: 14753 FINISHED_ROUND events: 139 THREAD_MAP events: 1 CPU_MAP events: 1 TIME_CONV events: 1 I had to check the output several times to ascertain that I'm not misreading the output, that the field didn't change and that I didn't misremember the name. In fact I had to look into the perf source to make sure that zero fields are indeed not shown. With the patch applied: fomalhaut:~> perf report --stat Aggregated stats: TOTAL events: 495984 MMAP events: 85 LOST events: 0 COMM events: 3389 EXIT events: 1605 THROTTLE events: 2 UNTHROTTLE events: 2 FORK events: 3377 READ events: 0 SAMPLE events: 472629 MMAP2 events: 14753 AUX events: 0 ITRACE_START events: 0 LOST_SAMPLES events: 0 SWITCH events: 0 SWITCH_CPU_WIDE events: 0 NAMESPACES events: 0 ATTR events: 0 EVENT_TYPE events: 0 TRACING_DATA events: 0 BUILD_ID events: 0 FINISHED_ROUND events: 139 ID_INDEX events: 0 AUXTRACE_INFO events: 0 AUXTRACE events: 0 AUXTRACE_ERROR events: 0 THREAD_MAP events: 1 CPU_MAP events: 1 STAT_CONFIG events: 0 STAT events: 0 STAT_ROUND events: 0 EVENT_UPDATE events: 0 TIME_CONV events: 1 FEATURE events: 0 It's pretty clear at a glance that LOST_SAMPLES is present but zero. The original output can still be gotten via: fomalhaut:~> perf report --stat | grep -vw 0 Aggregated stats: TOTAL events: 495984 MMAP events: 85 COMM events: 3389 EXIT events: 1605 THROTTLE events: 2 UNTHROTTLE events: 2 FORK events: 3377 SAMPLE events: 472629 MMAP2 events: 14753 FINISHED_ROUND events: 139 THREAD_MAP events: 1 CPU_MAP events: 1 TIME_CONV events: 1 So I don't think there's any real loss in functionality. Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20180307152430.7e5h7e657b7bgd7q@gmail.comSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Thomas Richter authored
Executing command 'perf stat -T -- ls' dumps core on x86 and s390. Here is the call back chain (done on x86): # gdb ./perf .... (gdb) r stat -T -- ls ... Program received signal SIGSEGV, Segmentation fault. 0x00007ffff56d1963 in vasprintf () from /lib64/libc.so.6 (gdb) where #0 0x00007ffff56d1963 in vasprintf () from /lib64/libc.so.6 #1 0x00007ffff56ae484 in asprintf () from /lib64/libc.so.6 #2 0x00000000004f1982 in __parse_events_add_pmu (parse_state=0x7fffffffd580, list=0xbfb970, name=0xbf3ef0 "cpu", head_config=0xbfb930, auto_merge_stats=false) at util/parse-events.c:1233 #3 0x00000000004f1c8e in parse_events_add_pmu (parse_state=0x7fffffffd580, list=0xbfb970, name=0xbf3ef0 "cpu", head_config=0xbfb930) at util/parse-events.c:1288 #4 0x0000000000537ce3 in parse_events_parse (_parse_state=0x7fffffffd580, scanner=0xbf4210) at util/parse-events.y:234 #5 0x00000000004f2c7a in parse_events__scanner (str=0x6b66c0 "task-clock,{instructions,cycles,cpu/cycles-t/,cpu/tx-start/}", parse_state=0x7fffffffd580, start_token=258) at util/parse-events.c:1673 #6 0x00000000004f2e23 in parse_events (evlist=0xbe9990, str=0x6b66c0 "task-clock,{instructions,cycles,cpu/cycles-t/,cpu/tx-start/}", err=0x0) at util/parse-events.c:1713 #7 0x000000000044e137 in add_default_attributes () at builtin-stat.c:2281 #8 0x000000000044f7b5 in cmd_stat (argc=1, argv=0x7fffffffe3b0) at builtin-stat.c:2828 #9 0x00000000004c8b0f in run_builtin (p=0xab01a0 <commands+288>, argc=4, argv=0x7fffffffe3b0) at perf.c:297 #10 0x00000000004c8d7c in handle_internal_command (argc=4, argv=0x7fffffffe3b0) at perf.c:349 #11 0x00000000004c8ece in run_argv (argcp=0x7fffffffe20c, argv=0x7fffffffe200) at perf.c:393 #12 0x00000000004c929c in main (argc=4, argv=0x7fffffffe3b0) at perf.c:537 (gdb) It turns out that a NULL pointer is referenced. Here are the function calls: ... cmd_stat() +---> add_default_attributes() +---> parse_events(evsel_list, transaction_attrs, NULL); 3rd parameter set to NULL Function parse_events(xx, xx, struct parse_events_error *err) dives into a bison generated scanner and creates parser state information for it first: struct parse_events_state parse_state = { .list = LIST_HEAD_INIT(parse_state.list), .idx = evlist->nr_entries, .error = err, <--- NULL POINTER !!! .evlist = evlist, }; Now various functions inside the bison scanner are called to end up in __parse_events_add_pmu(struct parse_events_state *parse_state, ..) with first parameter being a pointer to above structure definition. Now the PMU event name is not found (because being executed in a VM) and this function tries to create an error message with asprintf(&parse_state->error.str, ....) which references a NULL pointer and dumps core. Fix this by providing a pointer to the necessary error information instead of NULL. Technically only the else part is needed to avoid the core dump, just lets be safe... Signed-off-by: Thomas Richter <tmricht@linux.vnet.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Link: http://lkml.kernel.org/r/20180308145735.64717-1-tmricht@linux.vnet.ibm.comSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-