1. 19 Jul, 2017 25 commits
  2. 12 Jul, 2017 1 commit
    • Arnaldo Carvalho de Melo's avatar
      perf symbols: Accept zero as the kernel base address · 4b1303d0
      Arnaldo Carvalho de Melo authored
      Which is the case in S/390, where symbols were not being resolved
      because machine__get_kernel_start was only setting machine->kernel_start
      when the just successfully loaded kernel symtab had its map->start set
      to !0, when it was left at (1ULL << 63) assuming a partitioning of the
      address space for user/kernel, which is not the case in S/390 nor in
      Sparc.
      
      So just check if map__load() was successfull and set
      machine->kernel_start to zero, fixing kernel symbol resolution on S/390.
      
      Test performed by Thomas:
      
       ----
      
        I like this patch. I have done a new build and removed all my debug output to start
        from scratch. Without your patch I get this:
      
        # Samples: 4  of event 'cpu-clock'
        # Event count (approx.): 1000000
        #
        # Children      Self  Command  Shared Object     Symbol
        # ........  ........  .......  ................  ........................
            75.00%     0.00%  true     [unknown]         [k] 0x00000000004bedda
                    |
                    ---0x4bedda
                       |
                       |--50.00%--0x42693a
                       |          |
                       |           --25.00%--0x2a72e0
                       |                     0x2af0ca
                       |                     0x3d1003fe4c0
                       |
                        --25.00%--0x4272bc
                                  0x26fa84
      
        and with your patch (I just rebuilt the perf tool, nothing else and used the same
        perf.data file as input):
      
        # Samples: 4  of event 'cpu-clock'
        # Event count (approx.): 1000000
        #
        # Children      Self  Command  Shared Object               Symbol
        # ........  ........  .......  ..........................  ..................................
            75.00%     0.00%  true     [kernel.vmlinux]            [k] pgm_check_handler
                    |
                    ---pgm_check_handler
                       do_dat_exception
                       handle_mm_fault
                       __handle_mm_fault
                       filemap_map_pages
                       |
                       |--25.00%--rcu_read_lock_held
                       |          rcu_lockdep_current_cpu_online
                       |          0x3d1003ff4c0
                       |
                        --25.00%--lock_release
      
        Looks good to me....
       ----
      Reported-and-Tested-by: default avatarThomas-Mich Richter <tmricht@linux.vnet.ibm.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: Zvonko Kosic <zvonko.kosic@de.ibm.com>
      Link: http://lkml.kernel.org/n/tip-dk0n1uzmbe0tbthrpfqlx6bz@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      4b1303d0
  3. 11 Jul, 2017 2 commits
  4. 10 Jul, 2017 3 commits
  5. 08 Jul, 2017 3 commits
  6. 05 Jul, 2017 1 commit
  7. 04 Jul, 2017 5 commits
    • Jiri Olsa's avatar
      perf unwind: Do not fail due to missing unwind support · 1934adf7
      Jiri Olsa authored
      We currently fail the MMAP event processing if we don't have the MMAP
      event's specific arch unwind support compiled in.
      
      That's wrong and can lead to unresolved mmaps in report output for 32bit
      binaries on 64bit server, like in this example on x86_64 server:
      
        $ cat ex.c
        int main(int argc, char **argv)
        {
                while (1) {}
        }
        $ gcc -o ex -m32 ex.c
        $ perf record ./ex
        ^C[ perf record: Woken up 2 times to write data ]
        [ perf record: Captured and wrote 0.371 MB perf.data (9322 samples) ]
      
      Before:
        $ perf report --stdio
      
        SNIP
      
        # Overhead  Command  Shared Object     Symbol
        # ........  .......  ................  ......................
        #
           100.00%  ex       [unknown]         [.] 0x00000000080483de
             0.00%  ex       [unknown]         [.] 0x00000000f76dba4f
             0.00%  ex       [unknown]         [.] 0x00000000f76e4c11
             0.00%  ex       [unknown]         [.] 0x00000000f76daa30
      
      After:
        $ perf report --stdio
      
        SNIP
      
        # Overhead  Command  Shared Object  Symbol
        # ........  .......  .............  ...............
        #
           100.00%  ex       ex             [.] main
             0.00%  ex       ld-2.24.so     [.] _dl_start
             0.00%  ex       ld-2.24.so     [.] do_lookup_x
             0.00%  ex       ld-2.24.so     [.] _start
      
      The fix is not to fail, just warn if there's not unwind support compiled
      in.
      Reported-by: default avatarMichael Lyle <mlyle@lyle.org>
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20170704131131.27508-1-jolsa@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      1934adf7
    • Arnaldo Carvalho de Melo's avatar
      perf evsel: Set attr.exclude_kernel when probing max attr.precise_ip · 97365e81
      Arnaldo Carvalho de Melo authored
      We should set attr.exclude_kernel when probing for attr.precise_ip
      level, otherwise !CAP_SYS_ADMIN users will not default to skidless
      samples in capable hardware.
      
      The increase in the paranoid level in commit 0161028b ("perf/core:
      Change the default paranoia level to 2") broke this, fix it by excluding
      kernel samples when probing.
      
      Before:
      
        $ perf record usleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.018 MB perf.data (6 samples) ]
        $ perf evlist -v
        cycles:u: sample_freq: 4000, sample_type: IP|TID|TIME|PERIOD, exclude_kernel: 1
      
      After:
      
        $ perf record usleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.018 MB perf.data (8 samples) ]
        $ perf evlist -v
        cycles:ppp: sample_freq: 4000, sample_type: IP|TID|TIME|PERIOD, exclude_kernel: 1, precise_ip: 3
                                                                                           ^^^^^^^^^^^^^
                                                                                           ^^^^^^^^^^^^^
                                                                                           ^^^^^^^^^^^^^
        $
      
      To further clarify: we always set .exclude_kernel when non !CAP_SYS_ADMIN
      users profile, its just on the attr.precise_ip probing that we weren't doing
      so, fix it.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      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: 7f8d1ade ("perf tools: By default use the most precise "cycles" hw counter available")
      Link: http://lkml.kernel.org/n/tip-t2qttwhbnua62o5gt75cueml@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      97365e81
    • Linus Torvalds's avatar
      Merge branch 'ras-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 4422d80e
      Linus Torvalds authored
      Pull RAS updates from Thomas Gleixner:
       "The RAS updates for the 4.13 merge window:
      
         - Cleanup of the MCE injection facility (Borsilav Petkov)
      
         - Rework of the AMD/SMCA handling (Yazen Ghannam)
      
         - Enhancements for ACPI/APEI to handle new notitication types (Shiju
           Jose)
      
         - atomic_t to refcount_t conversion (Elena Reshetova)
      
         - A few fixes and enhancements all over the place"
      
      * 'ras-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        RAS/CEC: Check the correct variable in the debugfs error handling
        x86/mce: Always save severity in machine_check_poll()
        x86/MCE, xen/mcelog: Make /dev/mcelog registration messages more precise
        x86/mce: Update bootlog description to reflect behavior on AMD
        x86/mce: Don't disable MCA banks when offlining a CPU on AMD
        x86/mce/mce-inject: Preset the MCE injection struct
        x86/mce: Clean up include files
        x86/mce: Get rid of register_mce_write_callback()
        x86/mce: Merge mce_amd_inj into mce-inject
        x86/mce/AMD: Use saved threshold block info in interrupt handler
        x86/mce/AMD: Use msr_stat when clearing MCA_STATUS
        x86/mce/AMD: Carve out SMCA bank configuration
        x86/mce/AMD: Redo error logging from APIC LVT interrupt handlers
        x86/mce: Convert threshold_bank.cpus from atomic_t to refcount_t
        RAS: Make local function parse_ras_param() static
        ACPI/APEI: Handle GSIV and GPIO notification types
      4422d80e
    • Linus Torvalds's avatar
      Merge branch 'smp-hotplug-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 9a9594ef
      Linus Torvalds authored
      Pull SMP hotplug updates from Thomas Gleixner:
       "This update is primarily a cleanup of the CPU hotplug locking code.
      
        The hotplug locking mechanism is an open coded RWSEM, which allows
        recursive locking. The main problem with that is the recursive nature
        as it evades the full lockdep coverage and hides potential deadlocks.
      
        The rework replaces the open coded RWSEM with a percpu RWSEM and
        establishes full lockdep coverage that way.
      
        The bulk of the changes fix up recursive locking issues and address
        the now fully reported potential deadlocks all over the place. Some of
        these deadlocks have been observed in the RT tree, but on mainline the
        probability was low enough to hide them away."
      
      * 'smp-hotplug-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (37 commits)
        cpu/hotplug: Constify attribute_group structures
        powerpc: Only obtain cpu_hotplug_lock if called by rtasd
        ARM/hw_breakpoint: Fix possible recursive locking for arch_hw_breakpoint_init
        cpu/hotplug: Remove unused check_for_tasks() function
        perf/core: Don't release cred_guard_mutex if not taken
        cpuhotplug: Link lock stacks for hotplug callbacks
        acpi/processor: Prevent cpu hotplug deadlock
        sched: Provide is_percpu_thread() helper
        cpu/hotplug: Convert hotplug locking to percpu rwsem
        s390: Prevent hotplug rwsem recursion
        arm: Prevent hotplug rwsem recursion
        arm64: Prevent cpu hotplug rwsem recursion
        kprobes: Cure hotplug lock ordering issues
        jump_label: Reorder hotplug lock and jump_label_lock
        perf/tracing/cpuhotplug: Fix locking order
        ACPI/processor: Use cpu_hotplug_disable() instead of get_online_cpus()
        PCI: Replace the racy recursion prevention
        PCI: Use cpu_hotplug_disable() instead of get_online_cpus()
        perf/x86/intel: Drop get_online_cpus() in intel_snb_check_microcode()
        x86/perf: Drop EXPORT of perf_check_microcode
        ...
      9a9594ef
    • Linus Torvalds's avatar
      Merge branch 'x86-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 3ad918e6
      Linus Torvalds authored
      Pull x86 timers updates from Thomas Gleixner:
       "This update contains:
      
         - The solution for the TSC deadline timer borkage, which is caused by
           a hardware problem in the TSC_ADJUST/TSC_DEADLINE_TIMER logic.
      
           The problem is documented now and fixed with a microcode update, so
           we can remove the workaround and just check for the microcode version.
      
           If the microcode is not up to date, then the TSC deadline timer is
           disabled. If the borkage is fixed by the proper microcode version,
           then the deadline timer can be used. In both cases the restrictions
           to the range of the TSC_ADJUST value, which were added as
           workarounds, are removed.
      
        - A few simple fixes and updates to the timer related x86 code"
      
      * 'x86-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/tsc: Call check_system_tsc_reliable() before unsynchronized_tsc()
        x86/hpet: Do not use smp_processor_id() in preemptible code
        x86/time: Make setup_default_timer_irq() static
        x86/tsc: Remove the TSC_ADJUST clamp
        x86/apic: Add TSC_DEADLINE quirk due to errata
        x86/apic: Change the lapic name in deadline mode
      3ad918e6