1. 17 Dec, 2018 3 commits
  2. 01 Dec, 2018 1 commit
  3. 21 Nov, 2018 1 commit
  4. 13 Nov, 2018 7 commits
  5. 10 Nov, 2018 6 commits
    • Rasmus Villemoes's avatar
      perf tools: Disable parallelism for 'make clean' · 9a7f15ea
      Rasmus Villemoes authored
      [ Upstream commit da15fc2fa9c07b23db8f5e479bd8a9f0d741ca07 ]
      
      The Yocto build system does a 'make clean' when rebuilding due to
      changed dependencies, and that consistently fails for me (causing the
      whole BSP build to fail) with errors such as
      
      | find: '[...]/perf/1.0-r9/perf-1.0/plugin_mac80211.so': No such file or directory
      | find: '[...]/perf/1.0-r9/perf-1.0/plugin_mac80211.so': No such file or directory
      | find: find: '[...]/perf/1.0-r9/perf-1.0/libtraceevent.a''[...]/perf/1.0-r9/perf-1.0/libtraceevent.a': No such file or directory: No such file or directory
      |
      [...]
      | find: cannot delete '/mnt/xfs/devel/pil/yocto/tmp-glibc/work/wandboard-oe-linux-gnueabi/perf/1.0-r9/perf-1.0/util/.pstack.o.cmd': No such file or directory
      
      Apparently (despite the comment), 'make clean' ends up launching
      multiple sub-makes that all want to remove the same things - perhaps
      this only happens in combination with a O=... parameter. In any case, we
      don't lose much by explicitly disabling the parallelism for the clean
      target, and it makes automated builds much more reliable.
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Acked-by: default avatarJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20180705131527.19749-1-linux@rasmusvillemoes.dkSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9a7f15ea
    • Sandipan Das's avatar
      perf tests: Fix indexing when invoking subtests · 2fc0fb03
      Sandipan Das authored
      [ Upstream commit aa90f9f9554616d5738f7bedb4a8f0e5e14d1bc6 ]
      
      Recently, the subtest numbering was changed to start from 1.  While it
      is fine for displaying results, this should not be the case when the
      subtests are actually invoked.
      
      Typically, the subtests are stored in zero-indexed arrays and invoked
      based on the index passed to the main test function.  Since the index
      now starts from 1, the second subtest in the array (index 1) gets
      invoked instead of the first (index 0).  This applies to all of the
      following subtests but for the last one, the subtest always fails
      because it does not meet the boundary condition of the subtest index
      being lesser than the number of subtests.
      
      This can be observed on powerpc64 and x86_64 systems running Fedora 28
      as shown below.
      
      Before:
      
        # perf test "builtin clang support"
        55: builtin clang support                                 :
        55.1: builtin clang compile C source to IR                : Ok
        55.2: builtin clang compile C source to ELF object        : FAILED!
      
        # perf test "LLVM search and compile"
        38: LLVM search and compile                               :
        38.1: Basic BPF llvm compile                              : Ok
        38.2: kbuild searching                                    : Ok
        38.3: Compile source for BPF prologue generation          : Ok
        38.4: Compile source for BPF relocation                   : FAILED!
      
        # perf test "BPF filter"
        40: BPF filter                                            :
        40.1: Basic BPF filtering                                 : Ok
        40.2: BPF pinning                                         : Ok
        40.3: BPF prologue generation                             : Ok
        40.4: BPF relocation checker                              : FAILED!
      
      After:
      
        # perf test "builtin clang support"
        55: builtin clang support                                 :
        55.1: builtin clang compile C source to IR                : Ok
        55.2: builtin clang compile C source to ELF object        : Ok
      
        # perf test "LLVM search and compile"
        38: LLVM search and compile                               :
        38.1: Basic BPF llvm compile                              : Ok
        38.2: kbuild searching                                    : Ok
        38.3: Compile source for BPF prologue generation          : Ok
        38.4: Compile source for BPF relocation                   : Ok
      
        # perf test "BPF filter"
        40: BPF filter                                            :
        40.1: Basic BPF filtering                                 : Ok
        40.2: BPF pinning                                         : Ok
        40.3: BPF prologue generation                             : Ok
        40.4: BPF relocation checker                              : Ok
      Signed-off-by: default avatarSandipan Das <sandipan@linux.ibm.com>
      Reported-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Hendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Thomas Richter <tmricht@linux.ibm.com>
      Fixes: 9ef0112442bd ("perf test: Fix subtest number when showing results")
      Link: http://lkml.kernel.org/r/20180726171733.33208-1-sandipan@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2fc0fb03
    • Michael S. Tsirkin's avatar
      ptr_ring: fix up after recent ptr_ring changes · 7334e285
      Michael S. Tsirkin authored
      [ Upstream commit 5790eabc ]
      
      Add more stubs to make it build.
      
      Fixes: 81fbfe8a ("ptr_ring: use kmalloc_array()")
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7334e285
    • Björn Töpel's avatar
      perf probe: Fix probe definition for inlined functions · 2cdc70f3
      Björn Töpel authored
      [ Upstream commit 7598f8bc ]
      
      In commit 613f050d ("perf probe: Fix to probe on gcc generated
      functions in modules"), the offset from symbol is, incorrectly, added
      to the trace point address. This leads to incorrect probe trace points
      for inlined functions and when using relative line number on symbols.
      
      Prior this patch:
        $ perf probe -m nf_nat -D in_range
        p:probe/in_range nf_nat:in_range.isra.9+0
        $ perf probe -m i40e -D i40e_clean_rx_irq
        p:probe/i40e_clean_rx_irq i40e:i40e_napi_poll+2212
        $ perf probe -m i40e -D i40e_clean_rx_irq:16
        p:probe/i40e_clean_rx_irq i40e:i40e_lan_xmit_frame+626
      
      After:
        $ perf probe -m nf_nat -D in_range
        p:probe/in_range nf_nat:in_range.isra.9+0
        $ perf probe -m i40e -D i40e_clean_rx_irq
        p:probe/i40e_clean_rx_irq i40e:i40e_napi_poll+1106
        $ perf probe -m i40e -D i40e_clean_rx_irq:16
        p:probe/i40e_clean_rx_irq i40e:i40e_napi_poll+2665
      
      Committer testing:
      
      Using 'pfunct', a tool found in the 'dwarves' package [1], one can ask what are
      the functions that while not being explicitely marked as inline, were inlined
      by the compiler:
      
        # pfunct --cc_inlined /lib/modules/4.12.0-rc4+/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko | head
        __ew32
        e1000_regdump
        e1000e_dump_ps_pages
        e1000_desc_unused
        e1000e_systim_to_hwtstamp
        e1000e_rx_hwtstamp
        e1000e_update_rdt_wa
        e1000e_update_tdt_wa
        e1000_put_txbuf
        e1000_consume_page
      
      Then ask 'perf probe' to produce the kprobe_tracer probe definitions for two of
      them:
      
        # perf probe -m e1000e -D e1000e_rx_hwtstamp
        p:probe/e1000e_rx_hwtstamp e1000e:e1000_receive_skb+74
      
        # perf probe -m e1000e -D e1000_consume_page
        p:probe/e1000_consume_page e1000e:e1000_clean_jumbo_rx_irq+876
        p:probe/e1000_consume_page_1 e1000e:e1000_clean_jumbo_rx_irq+1506
        p:probe/e1000_consume_page_2 e1000e:e1000_clean_rx_irq_ps+1074
      
      Now lets concentrate on the 'e1000_consume_page' one, that was inlined twice in
      e1000_clean_jumbo_rx_irq(), lets see what readelf says about the DWARF tags for
      that function:
      
        $ readelf -wi /lib/modules/4.12.0-rc4+/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
        <SNIP>
        <1><13e27b>: Abbrev Number: 121 (DW_TAG_subprogram)
          <13e27c>   DW_AT_name        : (indirect string, offset: 0xa8945): e1000_clean_jumbo_rx_irq
          <13e287>   DW_AT_low_pc      : 0x17a30
        <3><13e6ef>: Abbrev Number: 119 (DW_TAG_inlined_subroutine)
          <13e6f0>   DW_AT_abstract_origin: <0x13ed2c>
          <13e6f4>   DW_AT_low_pc      : 0x17be6
        <SNIP>
        <1><13ed2c>: Abbrev Number: 142 (DW_TAG_subprogram)
           <13ed2e>   DW_AT_name        : (indirect string, offset: 0xa54c3): e1000_consume_page
      
      So, the first time in e1000_clean_jumbo_rx_irq() where e1000_consume_page() is
      inlined is at PC 0x17be6, which subtracted from e1000_clean_jumbo_rx_irq()'s
      address, gives us the offset we should use in the probe definition:
      
        0x17be6 - 0x17a30 = 438
      
      but above we have 876, which is twice as much.
      
      Lets see the second inline expansion of e1000_consume_page() in
      e1000_clean_jumbo_rx_irq():
      
        <3><13e86e>: Abbrev Number: 119 (DW_TAG_inlined_subroutine)
          <13e86f>   DW_AT_abstract_origin: <0x13ed2c>
          <13e873>   DW_AT_low_pc      : 0x17d21
      
        0x17d21 - 0x17a30 = 753
      
      So we where adding it at twice the offset from the containing function as we
      should.
      
      And then after this patch:
      
        # perf probe -m e1000e -D e1000e_rx_hwtstamp
        p:probe/e1000e_rx_hwtstamp e1000e:e1000_receive_skb+37
      
        # perf probe -m e1000e -D e1000_consume_page
        p:probe/e1000_consume_page e1000e:e1000_clean_jumbo_rx_irq+438
        p:probe/e1000_consume_page_1 e1000e:e1000_clean_jumbo_rx_irq+753
        p:probe/e1000_consume_page_2 e1000e:e1000_clean_jumbo_rx_irq+1353
        #
      
      Which matches the two first expansions and shows that because we were
      doubling the offset it would spill over the next function:
      
        readelf -sw /lib/modules/4.12.0-rc4+/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
         673: 0000000000017a30  1626 FUNC    LOCAL  DEFAULT    2 e1000_clean_jumbo_rx_irq
         674: 0000000000018090  2013 FUNC    LOCAL  DEFAULT    2 e1000_clean_rx_irq_ps
      
      This is the 3rd inline expansion of e1000_consume_page() in
      e1000_clean_jumbo_rx_irq():
      
         <3><13ec77>: Abbrev Number: 119 (DW_TAG_inlined_subroutine)
          <13ec78>   DW_AT_abstract_origin: <0x13ed2c>
          <13ec7c>   DW_AT_low_pc      : 0x17f79
      
        0x17f79 - 0x17a30 = 1353
      
       So:
      
         0x17a30 + 2 * 1353 = 0x184c2
      
        And:
      
         0x184c2 - 0x18090 = 1074
      
      Which explains the bogus third expansion for e1000_consume_page() to end up at:
      
         p:probe/e1000_consume_page_2 e1000e:e1000_clean_rx_irq_ps+1074
      
      All fixed now :-)
      
      [1] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/Signed-off-by: default avatarBjörn Töpel <bjorn.topel@intel.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Acked-by: default avatarMagnus Karlsson <magnus.karlsson@intel.com>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Cc: stable@vger.kernel.org
      Fixes: 613f050d ("perf probe: Fix to probe on gcc generated functions in modules")
      Link: http://lkml.kernel.org/r/20170621164134.5701-1-bjorn.topel@gmail.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2cdc70f3
    • Arnaldo Carvalho de Melo's avatar
      perf evsel: Fix probing of precise_ip level for default cycles event · 4d19a505
      Arnaldo Carvalho de Melo authored
      [ Upstream commit 7a1ac110 ]
      
      Since commit 18e7a45a ("perf/x86: Reject non sampling events with
      precise_ip") returns -EINVAL for sys_perf_event_open() with an attribute
      with (attr.precise_ip > 0 && attr.sample_period == 0), just like is done
      in the routine used to probe the max precise level when no events were
      passed to 'perf record' or 'perf top', i.e.:
      
      	perf_evsel__new_cycles()
      		perf_event_attr__set_max_precise_ip()
      
      The x86 code, in x86_pmu_hw_config(), which is called all the way from
      sys_perf_event_open() did, starting with the aforementioned commit:
      
                      /* There's no sense in having PEBS for non sampling events: */
                      if (!is_sampling_event(event))
                              return -EINVAL;
      
      Which makes it fail for cycles:ppp, cycles:pp and cycles:p, always using
      just the non precise cycles variant.
      
      To make sure that this is the case, I tested it, before this patch,
      with:
      
        # perf probe -L x86_pmu_hw_config
        <x86_pmu_hw_config@/home/acme/git/linux/arch/x86/events/core.c:0>
              0  int x86_pmu_hw_config(struct perf_event *event)
              1  {
              2         if (event->attr.precise_ip) {
      <SNIP>
             17                 if (event->attr.precise_ip > precise)
             18                         return -EOPNOTSUPP;
      
                                /* There's no sense in having PEBS for non sampling events: */
             21                 if (!is_sampling_event(event))
             22                         return -EINVAL;
                        }
      <SNIP>
        # perf probe x86_pmu_hw_config:22
        Added new events:
          probe:x86_pmu_hw_config (on x86_pmu_hw_config:22)
          probe:x86_pmu_hw_config_1 (on x86_pmu_hw_config:22)
      
        You can now use it in all perf tools, such as:
      
              perf record -e probe:x86_pmu_hw_config_1 -aR sleep 1
      
        # perf trace -e perf_event_open,probe:x86_pmu_hwconfig*/max-stack=16/ perf record usleep 1
           0.000 ( 0.015 ms): perf/4150 perf_event_open(attr_uptr: 0x7ffebc8ba110, cpu: -1, group_fd: -1      ) ...
           0.015 (         ): probe:x86_pmu_hw_config:(ffffffff9c0065e1))
                                             x86_pmu_hw_config ([kernel.kallsyms])
                                             hsw_hw_config ([kernel.kallsyms])
                                             x86_pmu_event_init ([kernel.kallsyms])
                                             perf_try_init_event ([kernel.kallsyms])
                                             perf_event_alloc ([kernel.kallsyms])
                                             SYSC_perf_event_open ([kernel.kallsyms])
                                             sys_perf_event_open ([kernel.kallsyms])
                                             do_syscall_64 ([kernel.kallsyms])
                                             return_from_SYSCALL_64 ([kernel.kallsyms])
                                             syscall (/usr/lib64/libc-2.24.so)
                                             perf_event_attr__set_max_precise_ip (/home/acme/bin/perf)
                                             perf_evsel__new_cycles (/home/acme/bin/perf)
                                             perf_evlist__add_default (/home/acme/bin/perf)
                                             cmd_record (/home/acme/bin/perf)
                                             run_builtin (/home/acme/bin/perf)
                                             handle_internal_command (/home/acme/bin/perf)
           0.000 ( 0.021 ms): perf/4150  ... [continued]: perf_event_open()) = -1 EINVAL Invalid argument
           0.023 ( 0.002 ms): perf/4150 perf_event_open(attr_uptr: 0x7ffebc8ba110, cpu: -1, group_fd: -1      ) ...
           0.025 (         ): probe:x86_pmu_hw_config:(ffffffff9c0065e1))
                                             x86_pmu_hw_config ([kernel.kallsyms])
                                             hsw_hw_config ([kernel.kallsyms])
                                             x86_pmu_event_init ([kernel.kallsyms])
                                             perf_try_init_event ([kernel.kallsyms])
                                             perf_event_alloc ([kernel.kallsyms])
                                             SYSC_perf_event_open ([kernel.kallsyms])
                                             sys_perf_event_open ([kernel.kallsyms])
                                             do_syscall_64 ([kernel.kallsyms])
                                             return_from_SYSCALL_64 ([kernel.kallsyms])
                                             syscall (/usr/lib64/libc-2.24.so)
                                             perf_event_attr__set_max_precise_ip (/home/acme/bin/perf)
                                             perf_evsel__new_cycles (/home/acme/bin/perf)
                                             perf_evlist__add_default (/home/acme/bin/perf)
                                             cmd_record (/home/acme/bin/perf)
                                             run_builtin (/home/acme/bin/perf)
                                             handle_internal_command (/home/acme/bin/perf)
           0.023 ( 0.004 ms): perf/4150  ... [continued]: perf_event_open()) = -1 EINVAL Invalid argument
           0.028 ( 0.002 ms): perf/4150 perf_event_open(attr_uptr: 0x7ffebc8ba110, cpu: -1, group_fd: -1      ) ...
           0.030 (         ): probe:x86_pmu_hw_config:(ffffffff9c0065e1))
                                             x86_pmu_hw_config ([kernel.kallsyms])
                                             hsw_hw_config ([kernel.kallsyms])
                                             x86_pmu_event_init ([kernel.kallsyms])
                                             perf_try_init_event ([kernel.kallsyms])
                                             perf_event_alloc ([kernel.kallsyms])
                                             SYSC_perf_event_open ([kernel.kallsyms])
                                             sys_perf_event_open ([kernel.kallsyms])
                                             do_syscall_64 ([kernel.kallsyms])
                                             return_from_SYSCALL_64 ([kernel.kallsyms])
                                             syscall (/usr/lib64/libc-2.24.so)
                                             perf_event_attr__set_max_precise_ip (/home/acme/bin/perf)
                                             perf_evsel__new_cycles (/home/acme/bin/perf)
                                             perf_evlist__add_default (/home/acme/bin/perf)
                                             cmd_record (/home/acme/bin/perf)
                                             run_builtin (/home/acme/bin/perf)
                                             handle_internal_command (/home/acme/bin/perf)
           0.028 ( 0.004 ms): perf/4150  ... [continued]: perf_event_open()) = -1 EINVAL Invalid argument
          41.018 ( 0.012 ms): perf/4150 perf_event_open(attr_uptr: 0x7ffebc8b5dd0, pid: -1, group_fd: -1, flags: FD_CLOEXEC) = 4
          41.065 ( 0.011 ms): perf/4150 perf_event_open(attr_uptr: 0x3c7db78, pid: -1, group_fd: -1, flags: FD_CLOEXEC) = 4
          41.080 ( 0.006 ms): perf/4150 perf_event_open(attr_uptr: 0x3c7db78, pid: -1, group_fd: -1, flags: FD_CLOEXEC) = 4
          41.103 ( 0.010 ms): perf/4150 perf_event_open(attr_uptr: 0x3c4e748, pid: 4151 (perf), group_fd: -1, flags: FD_CLOEXEC) = 4
          41.115 ( 0.006 ms): perf/4150 perf_event_open(attr_uptr: 0x3c4e748, pid: 4151 (perf), cpu: 1, group_fd: -1, flags: FD_CLOEXEC) = 5
          41.122 ( 0.004 ms): perf/4150 perf_event_open(attr_uptr: 0x3c4e748, pid: 4151 (perf), cpu: 2, group_fd: -1, flags: FD_CLOEXEC) = 6
          41.128 ( 0.008 ms): perf/4150 perf_event_open(attr_uptr: 0x3c4e748, pid: 4151 (perf), cpu: 3, group_fd: -1, flags: FD_CLOEXEC) = 8
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.017 MB perf.data (2 samples) ]
        #
      
      I.e. that return -EINVAL in x86_pmu_hw_config() is hit three times.
      
      So fix it by just setting attr.sample_period
      
      Now, after this patch:
      
        # perf trace --max-stack=2 -e perf_event_open,probe:x86_pmu_hw_config* perf record usleep 1
        [ perf record: Woken up 1 times to write data ]
           0.000 ( 0.017 ms): perf/8469 perf_event_open(attr_uptr: 0x7ffe36c27d10, pid: -1, cpu: 3, group_fd: -1, flags: FD_CLOEXEC) = 4
                                             syscall (/usr/lib64/libc-2.24.so)
                                             perf_event_open_cloexec_flag (/home/acme/bin/perf)
           0.050 ( 0.031 ms): perf/8469 perf_event_open(attr_uptr: 0x24ebb78, pid: -1, group_fd: -1, flags: FD_CLOEXEC) = 4
                                             syscall (/usr/lib64/libc-2.24.so)
                                             perf_evlist__config (/home/acme/bin/perf)
           0.092 ( 0.040 ms): perf/8469 perf_event_open(attr_uptr: 0x24ebb78, pid: -1, group_fd: -1, flags: FD_CLOEXEC) = 4
                                             syscall (/usr/lib64/libc-2.24.so)
                                             perf_evlist__config (/home/acme/bin/perf)
           0.143 ( 0.007 ms): perf/8469 perf_event_open(attr_uptr: 0x24bc748, cpu: -1, group_fd: -1           ) = 4
                                             syscall (/usr/lib64/libc-2.24.so)
                                             perf_event_attr__set_max_precise_ip (/home/acme/bin/perf)
           0.161 ( 0.007 ms): perf/8469 perf_event_open(attr_uptr: 0x24bc748, pid: 8470 (perf), group_fd: -1, flags: FD_CLOEXEC) = 4
                                             syscall (/usr/lib64/libc-2.24.so)
                                             perf_evsel__open (/home/acme/bin/perf)
           0.171 ( 0.005 ms): perf/8469 perf_event_open(attr_uptr: 0x24bc748, pid: 8470 (perf), cpu: 1, group_fd: -1, flags: FD_CLOEXEC) = 5
                                             syscall (/usr/lib64/libc-2.24.so)
                                             perf_evsel__open (/home/acme/bin/perf)
           0.180 ( 0.007 ms): perf/8469 perf_event_open(attr_uptr: 0x24bc748, pid: 8470 (perf), cpu: 2, group_fd: -1, flags: FD_CLOEXEC) = 6
                                             syscall (/usr/lib64/libc-2.24.so)
                                             perf_evsel__open (/home/acme/bin/perf)
           0.190 ( 0.005 ms): perf/8469 perf_event_open(attr_uptr: 0x24bc748, pid: 8470 (perf), cpu: 3, group_fd: -1, flags: FD_CLOEXEC) = 8
                                             syscall (/usr/lib64/libc-2.24.so)
                                             perf_evsel__open (/home/acme/bin/perf)
        [ perf record: Captured and wrote 0.017 MB perf.data (7 samples) ]
        #
      
      The probe one called from perf_event_attr__set_max_precise_ip() works
      the first time, with attr.precise_ip = 3, wit hthe next ones being the
      per cpu ones for the cycles:ppp event.
      
      And here is the text from a report and alternative proposed patch by
      Thomas-Mich Richter:
      
       ---
      
      On s390 the counter and sampling facility do not support a precise IP
      skid level and sometimes returns EOPNOTSUPP when structure member
      precise_ip in struct perf_event_attr is not set to zero.
      
      On s390 commnd 'perf record -- true' fails with error EOPNOTSUPP.  This
      happens only when no events are specified on command line.
      
      The functions called are
      ...
        --> perf_evlist__add_default
            --> perf_evsel__new_cycles
                --> perf_event_attr__set_max_precise_ip
      
      The last function determines the value of structure member precise_ip by
      invoking the perf_event_open() system call and checking the return code.
      The first successful open is the value for precise_ip.
      
      However the value is determined without setting member sample_period and
      indicates no sampling.
      
      On s390 the counter facility and sampling facility are different.  The
      above procedure determines a precise_ip value of 3 using the counter
      facility. Later it uses the sampling facility with a value of 3 and
      fails with EOPNOTSUPP.
      
       ---
      
      v2: Older compilers (e.g. gcc 4.4.7) don't support referencing members
          of unnamed union members in the container struct initialization, so
          move from:
      
      	struct perf_event_attr attr = {
      		...
      		.sample_period = 1,
      	};
      
      to right after it as:
      
      	struct perf_event_attr attr = {
      		...
      	};
      
      	attr.sample_period = 1;
      
      v3: We need to reset .sample_period to 0 to let the users of
      perf_evsel__new_cycles() to properly setup attr.sample_period or
      attr.sample_freq. Reported by Ingo Molnar.
      Reported-and-Acked-by: default avatarThomas-Mich Richter <tmricht@linux.vnet.ibm.com>
      Acked-by: default avatarHendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Acked-by: default avatarJiri Olsa <jolsa@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.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>
      Cc: Wang Nan <wangnan0@huawei.com>
      Fixes: 18e7a45a ("perf/x86: Reject non sampling events with precise_ip")
      Link: http://lkml.kernel.org/n/tip-yv6nnkl7tzqocrm0hl3x7vf1@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4d19a505
    • Ravi Bangoria's avatar
      perf symbols: Fix memory corruption because of zero length symbols · 698f6acd
      Ravi Bangoria authored
      [ Upstream commit 331c7cb3 ]
      
      Perf top is often crashing at very random locations on powerpc.  After
      investigating, I found the crash only happens when sample is of zero
      length symbol. Powerpc kernel has many such symbols which does not
      contain length details in vmlinux binary and thus start and end
      addresses of such symbols are same.
      
      Structure
      
        struct sym_hist {
              u64                   nr_samples;
              u64                   period;
              struct sym_hist_entry addr[0];
        };
      
      has last member 'addr[]' of size zero. 'addr[]' is an array of addresses
      that belongs to one symbol (function). If function consist of 100
      instructions, 'addr' points to an array of 100 'struct sym_hist_entry'
      elements. For zero length symbol, it points to the *empty* array, i.e.
      no members in the array and thus offset 0 is also invalid for such
      array.
      
        static int __symbol__inc_addr_samples(...)
        {
              ...
              offset = addr - sym->start;
              h = annotation__histogram(notes, evidx);
              h->nr_samples++;
              h->addr[offset].nr_samples++;
              h->period += sample->period;
              h->addr[offset].period += sample->period;
              ...
        }
      
      Here, when 'addr' is same as 'sym->start', 'offset' becomes 0, which is
      valid for normal symbols but *invalid* for zero length symbols and thus
      updating h->addr[offset] causes memory corruption.
      
      Fix this by adding one dummy element for zero length symbols.
      
      Link: https://lkml.org/lkml/2016/10/10/148
      Fixes: edee44be ("perf annotate: Don't throw error for zero length symbols")
      Signed-off-by: default avatarRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Acked-by: default avatarJiri Olsa <jolsa@kernel.org>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Taeung Song <treeze.taeung@gmail.com>
      Link: http://lkml.kernel.org/r/1508854806-10542-1-git-send-email-ravi.bangoria@linux.vnet.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      698f6acd
  6. 18 Oct, 2018 3 commits
  7. 13 Oct, 2018 2 commits
  8. 10 Oct, 2018 4 commits
  9. 26 Sep, 2018 5 commits
    • John Stultz's avatar
      selftest: timers: Tweak raw_skew to SKIP when ADJ_OFFSET/other clock adjustments are in progress · 18e589f6
      John Stultz authored
      [ Upstream commit 1416270f4a1ae83ea84156ceba19a66a8f88be1f ]
      
      In the past we've warned when ADJ_OFFSET was in progress, usually
      caused by ntpd or some other time adjusting daemon running in non
      steady sate, which can cause the skew calculations to be
      incorrect.
      
      Thus, this patch checks to see if the clock was being adjusted
      when we fail so that we don't cause false negatives.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Miroslav Lichvar <mlichvar@redhat.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Stephen Boyd <sboyd@kernel.org>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: linux-kselftest@vger.kernel.org
      Suggested-by: default avatarMiroslav Lichvar <mlichvar@redhat.com>
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      18e589f6
    • K. Y. Srinivasan's avatar
      Tools: hv: Fix a bug in the key delete code · 2516ead0
      K. Y. Srinivasan authored
      commit 86503bd35dec0ce363e9fdbf5299927422ed3899 upstream.
      
      Fix a bug in the key delete code - the num_records range
      from 0 to num_records-1.
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Reported-by: default avatarDavid Binderman <dcb314@hotmail.com>
      Cc: <stable@vger.kernel.org>
      Reviewed-by: default avatarMichael Kelley <mikelley@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2516ead0
    • Sandipan Das's avatar
      perf powerpc: Fix callchain ip filtering · 24dc2f57
      Sandipan Das authored
      [ Upstream commit c715fcfda5a08edabaa15508742be926b7ee51db ]
      
      For powerpc64, redundant entries in the callchain are filtered out by
      determining the state of the return address and the stack frame using
      DWARF debug information.
      
      For making these filtering decisions we must analyze the debug
      information for the location corresponding to the program counter value,
      i.e. the first entry in the callchain, and not the LR value; otherwise,
      perf may filter out either the second or the third entry in the
      callchain incorrectly.
      
      This can be observed on a powerpc64le system running Fedora 27 as shown
      below.
      
      Case 1 - Attaching a probe at inet_pton+0x8 (binary offset 0x15af28).
               Return address is still in LR and a new stack frame is not yet
               allocated. The LR value, i.e. the second entry, should not be
      	 filtered out.
      
        # objdump -d /usr/lib64/libc-2.26.so | less
        ...
        000000000010eb10 <gaih_inet.constprop.7>:
        ...
          10fa48:       78 bb e4 7e     mr      r4,r23
          10fa4c:       0a 00 60 38     li      r3,10
          10fa50:       d9 b4 04 48     bl      15af28 <inet_pton+0x8>
          10fa54:       00 00 00 60     nop
          10fa58:       ac f4 ff 4b     b       10ef04 <gaih_inet.constprop.7+0x3f4>
        ...
        0000000000110450 <getaddrinfo>:
        ...
          1105a8:       54 00 ff 38     addi    r7,r31,84
          1105ac:       58 00 df 38     addi    r6,r31,88
          1105b0:       69 e5 ff 4b     bl      10eb18 <gaih_inet.constprop.7+0x8>
          1105b4:       78 1b 71 7c     mr      r17,r3
          1105b8:       50 01 7f e8     ld      r3,336(r31)
        ...
        000000000015af20 <inet_pton>:
          15af20:       0b 00 4c 3c     addis   r2,r12,11
          15af24:       e0 c1 42 38     addi    r2,r2,-15904
          15af28:       a6 02 08 7c     mflr    r0
          15af2c:       f0 ff c1 fb     std     r30,-16(r1)
          15af30:       f8 ff e1 fb     std     r31,-8(r1)
        ...
      
        # perf probe -x /usr/lib64/libc-2.26.so -a inet_pton+0x8
        # perf record -e probe_libc:inet_pton -g ping -6 -c 1 ::1
        # perf script
      
      Before:
      
        ping  4507 [002] 514985.546540: probe_libc:inet_pton: (7fffa7dbaf28)
                    7fffa7dbaf28 __GI___inet_pton+0x8 (/usr/lib64/libc-2.26.so)
                    7fffa7d705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
                       13fb52d70 _init+0xbfc (/usr/bin/ping)
                    7fffa7c836a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so)
                    7fffa7c83898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
                               0 [unknown] ([unknown])
      
      After:
      
        ping  4507 [002] 514985.546540: probe_libc:inet_pton: (7fffa7dbaf28)
                    7fffa7dbaf28 __GI___inet_pton+0x8 (/usr/lib64/libc-2.26.so)
                    7fffa7d6fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so)
                    7fffa7d705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
                       13fb52d70 _init+0xbfc (/usr/bin/ping)
                    7fffa7c836a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so)
                    7fffa7c83898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
                               0 [unknown] ([unknown])
      
      Case 2 - Attaching a probe at _int_malloc+0x180 (binary offset 0x9cf10).
               Return address in still in LR and a new stack frame has already
               been allocated but not used. The caller's caller, i.e. the third
      	 entry, is invalid and should be filtered out and not the second
      	 one.
      
        # objdump -d /usr/lib64/libc-2.26.so | less
        ...
        000000000009cd90 <_int_malloc>:
           9cd90:       17 00 4c 3c     addis   r2,r12,23
           9cd94:       70 a3 42 38     addi    r2,r2,-23696
           9cd98:       26 00 80 7d     mfcr    r12
           9cd9c:       f8 ff e1 fb     std     r31,-8(r1)
           9cda0:       17 00 e4 3b     addi    r31,r4,23
           9cda4:       d8 ff 61 fb     std     r27,-40(r1)
           9cda8:       78 23 9b 7c     mr      r27,r4
           9cdac:       1f 00 bf 2b     cmpldi  cr7,r31,31
           9cdb0:       f0 ff c1 fb     std     r30,-16(r1)
           9cdb4:       b0 ff c1 fa     std     r22,-80(r1)
           9cdb8:       78 1b 7e 7c     mr      r30,r3
           9cdbc:       08 00 81 91     stw     r12,8(r1)
           9cdc0:       11 ff 21 f8     stdu    r1,-240(r1)
           9cdc4:       4c 01 9d 41     bgt     cr7,9cf10 <_int_malloc+0x180>
           9cdc8:       20 00 a4 2b     cmpldi  cr7,r4,32
        ...
           9cf08:       00 00 00 60     nop
           9cf0c:       00 00 42 60     ori     r2,r2,0
           9cf10:       e4 06 ff 7b     rldicr  r31,r31,0,59
           9cf14:       40 f8 a4 7f     cmpld   cr7,r4,r31
           9cf18:       68 05 9d 41     bgt     cr7,9d480 <_int_malloc+0x6f0>
        ...
        000000000009e3c0 <tcache_init.part.4>:
        ...
           9e420:       40 02 80 38     li      r4,576
           9e424:       78 fb e3 7f     mr      r3,r31
           9e428:       71 e9 ff 4b     bl      9cd98 <_int_malloc+0x8>
           9e42c:       00 00 a3 2f     cmpdi   cr7,r3,0
           9e430:       78 1b 7e 7c     mr      r30,r3
        ...
        000000000009f7a0 <__libc_malloc>:
        ...
           9f8f8:       00 00 89 2f     cmpwi   cr7,r9,0
           9f8fc:       1c ff 9e 40     bne     cr7,9f818 <__libc_malloc+0x78>
           9f900:       c9 ea ff 4b     bl      9e3c8 <tcache_init.part.4+0x8>
           9f904:       00 00 00 60     nop
           9f908:       e8 90 22 e9     ld      r9,-28440(r2)
        ...
      
        # perf probe -x /usr/lib64/libc-2.26.so -a _int_malloc+0x180
        # perf record -e probe_libc:_int_malloc -g ./test-malloc
        # perf script
      
      Before:
      
        test-malloc  6554 [009] 515975.797403: probe_libc:_int_malloc: (7fffa6e6cf10)
                    7fffa6e6cf10 _int_malloc+0x180 (/usr/lib64/libc-2.26.so)
                    7fffa6dd0000 [unknown] (/usr/lib64/libc-2.26.so)
                    7fffa6e6f904 malloc+0x164 (/usr/lib64/libc-2.26.so)
                    7fffa6e6f9fc malloc+0x25c (/usr/lib64/libc-2.26.so)
                        100006b4 main+0x38 (/home/testuser/test-malloc)
                    7fffa6df36a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so)
                    7fffa6df3898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
                               0 [unknown] ([unknown])
      
      After:
      
        test-malloc  6554 [009] 515975.797403: probe_libc:_int_malloc: (7fffa6e6cf10)
                    7fffa6e6cf10 _int_malloc+0x180 (/usr/lib64/libc-2.26.so)
                    7fffa6e6e42c tcache_init.part.4+0x6c (/usr/lib64/libc-2.26.so)
                    7fffa6e6f904 malloc+0x164 (/usr/lib64/libc-2.26.so)
                    7fffa6e6f9fc malloc+0x25c (/usr/lib64/libc-2.26.so)
                        100006b4 main+0x38 (/home/sandipan/test-malloc)
                    7fffa6df36a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so)
                    7fffa6df3898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
                               0 [unknown] ([unknown])
      Signed-off-by: default avatarSandipan Das <sandipan@linux.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Maynard Johnson <maynard@us.ibm.com>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Fixes: a60335ba ("perf tools powerpc: Adjust callchain based on DWARF debug info")
      Link: http://lkml.kernel.org/r/24bb726d91ed173aebc972ec3f41a2ef2249434e.1530724939.git.sandipan@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      24dc2f57
    • Sandipan Das's avatar
      perf powerpc: Fix callchain ip filtering when return address is in a register · 14f3d651
      Sandipan Das authored
      [ Upstream commit 9068533e4f470daf2b0f29c71d865990acd8826e ]
      
      For powerpc64, perf will filter out the second entry in the callchain,
      i.e. the LR value, if the return address of the function corresponding
      to the probed location has already been saved on its caller's stack.
      
      The state of the return address is determined using debug information.
      At any point within a function, if the return address is already saved
      somewhere, a DWARF expression can tell us about its location. If the
      return address in still in LR only, no DWARF expression would exist.
      
      Typically, the instructions in a function's prologue first copy the LR
      value to R0 and then pushes R0 on to the stack. If LR has already been
      copied to R0 but R0 is yet to be pushed to the stack, we can still get a
      DWARF expression that says that the return address is in R0. This is
      indicating that getting a DWARF expression for the return address does
      not guarantee the fact that it has already been saved on the stack.
      
      This can be observed on a powerpc64le system running Fedora 27 as shown
      below.
      
        # objdump -d /usr/lib64/libc-2.26.so | less
        ...
        000000000015af20 <inet_pton>:
          15af20:       0b 00 4c 3c     addis   r2,r12,11
          15af24:       e0 c1 42 38     addi    r2,r2,-15904
          15af28:       a6 02 08 7c     mflr    r0
          15af2c:       f0 ff c1 fb     std     r30,-16(r1)
          15af30:       f8 ff e1 fb     std     r31,-8(r1)
          15af34:       78 1b 7f 7c     mr      r31,r3
          15af38:       78 23 83 7c     mr      r3,r4
          15af3c:       78 2b be 7c     mr      r30,r5
          15af40:       10 00 01 f8     std     r0,16(r1)
          15af44:       c1 ff 21 f8     stdu    r1,-64(r1)
          15af48:       28 00 81 f8     std     r4,40(r1)
        ...
      
        # readelf --debug-dump=frames-interp /usr/lib64/libc-2.26.so | less
        ...
        00027024 0000000000000024 00027028 FDE cie=00000000 pc=000000000015af20..000000000015af88
           LOC           CFA      r30   r31   ra
        000000000015af20 r1+0     u     u     u
        000000000015af34 r1+0     c-16  c-8   r0
        000000000015af48 r1+64    c-16  c-8   c+16
        000000000015af5c r1+0     c-16  c-8   c+16
        000000000015af78 r1+0     u     u
        ...
      
        # perf probe -x /usr/lib64/libc-2.26.so -a inet_pton+0x18
        # perf record -e probe_libc:inet_pton -g ping -6 -c 1 ::1
        # perf script
      
      Before:
      
        ping  2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38)
                    7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so)
                    7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
                       12f152d70 _init+0xbfc (/usr/bin/ping)
                    7fff7e1836a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so)
                    7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
                               0 [unknown] ([unknown])
      
      After:
      
        ping  2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38)
                    7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so)
                    7fff7e26fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so)
                    7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
                       12f152d70 _init+0xbfc (/usr/bin/ping)
                    7fff7e1836a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so)
                    7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
                               0 [unknown] ([unknown])
      Reported-by: default avatarRavi Bangoria <ravi.bangoria@linux.ibm.com>
      Signed-off-by: default avatarSandipan Das <sandipan@linux.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Maynard Johnson <maynard@us.ibm.com>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/66e848a7bdf2d43b39210a705ff6d828a0865661.1530724939.git.sandipan@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      14f3d651
    • Thomas Richter's avatar
      perf test: Fix subtest number when showing results · 48c37aa3
      Thomas Richter authored
      [ Upstream commit 9ef0112442bdddef5fb55adf20b3a5464b33de75 ]
      
      Perf test 40 for example has several subtests numbered 1-4 when
      displaying the start of the subtest. When the subtest results
      are displayed the subtests are numbered 0-3.
      
      Use this command to generate trace output:
      
        [root@s35lp76 perf]# ./perf test -Fv 40 2>/tmp/bpf1
      
      Fix this by adjusting the subtest number when show the
      subtest result.
      
      Output before:
      
        [root@s35lp76 perf]# egrep '(^40\.[0-4]| subtest [0-4]:)' /tmp/bpf1
        40.1: Basic BPF filtering                                 :
        BPF filter subtest 0: Ok
        40.2: BPF pinning                                         :
        BPF filter subtest 1: Ok
        40.3: BPF prologue generation                             :
        BPF filter subtest 2: Ok
        40.4: BPF relocation checker                              :
        BPF filter subtest 3: Ok
        [root@s35lp76 perf]#
      
      Output after:
      
        root@s35lp76 ~]# egrep '(^40\.[0-4]| subtest [0-4]:)' /tmp/bpf1
        40.1: Basic BPF filtering                                 :
        BPF filter subtest 1: Ok
        40.2: BPF pinning                                         :
        BPF filter subtest 2: Ok
        40.3: BPF prologue generation                             :
        BPF filter subtest 3: Ok
        40.4: BPF relocation checker                              :
        BPF filter subtest 4: Ok
        [root@s35lp76 ~]#
      Signed-off-by: default avatarThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: default avatarHendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Link: http://lkml.kernel.org/r/20180724134858.100644-1-tmricht@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      48c37aa3
  10. 19 Sep, 2018 1 commit
    • Christophe Leroy's avatar
      perf tools: Allow overriding MAX_NR_CPUS at compile time · 2a19b49a
      Christophe Leroy authored
      [ Upstream commit 21b8732eb4479b579bda9ee38e62b2c312c2a0e5 ]
      
      After update of kernel, the perf tool doesn't run anymore on my 32MB RAM
      powerpc board, but still runs on a 128MB RAM board:
      
        ~# strace perf
        execve("/usr/sbin/perf", ["perf"], [/* 12 vars */]) = -1 ENOMEM (Cannot allocate memory)
        --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
        +++ killed by SIGSEGV +++
        Segmentation fault
      
      objdump -x shows that .bss section has a huge size of 24Mbytes:
      
       27 .bss          016baca8  101cebb8  101cebb8  001cd988  2**3
      
      With especially the following objects having quite big size:
      
        10205f80 l     O .bss	00140000     runtime_cycles_stats
        10345f80 l     O .bss	00140000     runtime_stalled_cycles_front_stats
        10485f80 l     O .bss	00140000     runtime_stalled_cycles_back_stats
        105c5f80 l     O .bss	00140000     runtime_branches_stats
        10705f80 l     O .bss	00140000     runtime_cacherefs_stats
        10845f80 l     O .bss	00140000     runtime_l1_dcache_stats
        10985f80 l     O .bss	00140000     runtime_l1_icache_stats
        10ac5f80 l     O .bss	00140000     runtime_ll_cache_stats
        10c05f80 l     O .bss	00140000     runtime_itlb_cache_stats
        10d45f80 l     O .bss	00140000     runtime_dtlb_cache_stats
        10e85f80 l     O .bss	00140000     runtime_cycles_in_tx_stats
        10fc5f80 l     O .bss	00140000     runtime_transaction_stats
        11105f80 l     O .bss	00140000     runtime_elision_stats
        11245f80 l     O .bss	00140000     runtime_topdown_total_slots
        11385f80 l     O .bss	00140000     runtime_topdown_slots_retired
        114c5f80 l     O .bss	00140000     runtime_topdown_slots_issued
        11605f80 l     O .bss	00140000     runtime_topdown_fetch_bubbles
        11745f80 l     O .bss	00140000     runtime_topdown_recovery_bubbles
      
      This is due to commit 4d255766 ("perf: Bump max number of cpus
      to 1024"), because many tables are sized with MAX_NR_CPUS
      
      This patch gives the opportunity to redefine MAX_NR_CPUS via
      
        $ make EXTRA_CFLAGS=-DMAX_NR_CPUS=1
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Link: http://lkml.kernel.org/r/20170922112043.8349468C57@po15668-vm-win7.idsi0.si.c-s.frSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2a19b49a
  11. 15 Sep, 2018 2 commits
    • Breno Leitao's avatar
      selftests/powerpc: Kill child processes on SIGINT · 82e1e872
      Breno Leitao authored
      [ Upstream commit 7c27a26e1ed5a7dd709aa19685d2c98f64e1cf0c ]
      
      There are some powerpc selftests, as tm/tm-unavailable, that run for a long
      period (>120 seconds), and if it is interrupted, as pressing CRTL-C
      (SIGINT), the foreground process (harness) dies but the child process and
      threads continue to execute (with PPID = 1 now) in background.
      
      In this case, you'd think the whole test exited, but there are remaining
      threads and processes being executed in background. Sometimes these
      zombies processes are doing annoying things, as consuming the whole CPU or
      dumping things to STDOUT.
      
      This patch fixes this problem by attaching an empty signal handler to
      SIGINT in the harness process. This handler will interrupt (EINTR) the
      parent process waitpid() call, letting the code to follow through the
      normal flow, which will kill all the processes in the child process group.
      
      This patch also fixes a typo.
      Signed-off-by: default avatarBreno Leitao <leitao@debian.org>
      Signed-off-by: default avatarGustavo Romero <gromero@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      82e1e872
    • Sandipan Das's avatar
      perf probe powerpc: Fix trace event post-processing · 6841830a
      Sandipan Das authored
      [ Upstream commit 354b064b8ebc1e1ede58550ca9e08bfa81e6af43 ]
      
      In some cases, a symbol may have multiple aliases. Attempting to add an
      entry probe for such symbols results in a probe being added at an
      incorrect location while it fails altogether for return probes. This is
      only applicable for binaries with debug information.
      
      During the arch-dependent post-processing, the offset from the start of
      the symbol at which the probe is to be attached is determined and added
      to the start address of the symbol to get the probe's location.  In case
      there are multiple aliases, this offset gets added multiple times for
      each alias of the symbol and we end up with an incorrect probe location.
      
      This can be verified on a powerpc64le system as shown below.
      
        $ nm /lib/modules/$(uname -r)/build/vmlinux | grep "sys_open$"
        ...
        c000000000414290 T __se_sys_open
        c000000000414290 T sys_open
      
        $ objdump -d /lib/modules/$(uname -r)/build/vmlinux | grep -A 10 "<__se_sys_open>:"
      
        c000000000414290 <__se_sys_open>:
        c000000000414290:       19 01 4c 3c     addis   r2,r12,281
        c000000000414294:       70 c4 42 38     addi    r2,r2,-15248
        c000000000414298:       a6 02 08 7c     mflr    r0
        c00000000041429c:       e8 ff a1 fb     std     r29,-24(r1)
        c0000000004142a0:       f0 ff c1 fb     std     r30,-16(r1)
        c0000000004142a4:       f8 ff e1 fb     std     r31,-8(r1)
        c0000000004142a8:       10 00 01 f8     std     r0,16(r1)
        c0000000004142ac:       c1 ff 21 f8     stdu    r1,-64(r1)
        c0000000004142b0:       78 23 9f 7c     mr      r31,r4
        c0000000004142b4:       78 1b 7e 7c     mr      r30,r3
      
        For both the entry probe and the return probe, the probe location
        should be _text+4276888 (0xc000000000414298). Since another alias
        exists for 'sys_open', the post-processing code will end up adding
        the offset (8 for powerpc64le) twice and perf will attempt to add
        the probe at _text+4276896 (0xc0000000004142a0) instead.
      
      Before:
      
        # perf probe -v -a sys_open
      
        probe-definition(0): sys_open
        symbol:sys_open file:(null) line:0 offset:0 return:0 lazy:(null)
        0 arguments
        Looking at the vmlinux_path (8 entries long)
        Using /lib/modules/4.18.0-rc8+/build/vmlinux for symbols
        Open Debuginfo file: /lib/modules/4.18.0-rc8+/build/vmlinux
        Try to find probe point from debuginfo.
        Symbol sys_open address found : c000000000414290
        Matched function: __se_sys_open [2ad03a0]
        Probe point found: __se_sys_open+0
        Found 1 probe_trace_events.
        Opening /sys/kernel/debug/tracing/kprobe_events write=1
        Writing event: p:probe/sys_open _text+4276896
        Added new event:
          probe:sys_open       (on sys_open)
        ...
      
        # perf probe -v -a sys_open%return $retval
      
        probe-definition(0): sys_open%return
        symbol:sys_open file:(null) line:0 offset:0 return:1 lazy:(null)
        0 arguments
        Looking at the vmlinux_path (8 entries long)
        Using /lib/modules/4.18.0-rc8+/build/vmlinux for symbols
        Open Debuginfo file: /lib/modules/4.18.0-rc8+/build/vmlinux
        Try to find probe point from debuginfo.
        Symbol sys_open address found : c000000000414290
        Matched function: __se_sys_open [2ad03a0]
        Probe point found: __se_sys_open+0
        Found 1 probe_trace_events.
        Opening /sys/kernel/debug/tracing/README write=0
        Opening /sys/kernel/debug/tracing/kprobe_events write=1
        Parsing probe_events: p:probe/sys_open _text+4276896
        Group:probe Event:sys_open probe:p
        Writing event: r:probe/sys_open__return _text+4276896
        Failed to write event: Invalid argument
          Error: Failed to add events. Reason: Invalid argument (Code: -22)
      
      After:
      
        # perf probe -v -a sys_open
      
        probe-definition(0): sys_open
        symbol:sys_open file:(null) line:0 offset:0 return:0 lazy:(null)
        0 arguments
        Looking at the vmlinux_path (8 entries long)
        Using /lib/modules/4.18.0-rc8+/build/vmlinux for symbols
        Open Debuginfo file: /lib/modules/4.18.0-rc8+/build/vmlinux
        Try to find probe point from debuginfo.
        Symbol sys_open address found : c000000000414290
        Matched function: __se_sys_open [2ad03a0]
        Probe point found: __se_sys_open+0
        Found 1 probe_trace_events.
        Opening /sys/kernel/debug/tracing/kprobe_events write=1
        Writing event: p:probe/sys_open _text+4276888
        Added new event:
          probe:sys_open       (on sys_open)
        ...
      
        # perf probe -v -a sys_open%return $retval
      
        probe-definition(0): sys_open%return
        symbol:sys_open file:(null) line:0 offset:0 return:1 lazy:(null)
        0 arguments
        Looking at the vmlinux_path (8 entries long)
        Using /lib/modules/4.18.0-rc8+/build/vmlinux for symbols
        Open Debuginfo file: /lib/modules/4.18.0-rc8+/build/vmlinux
        Try to find probe point from debuginfo.
        Symbol sys_open address found : c000000000414290
        Matched function: __se_sys_open [2ad03a0]
        Probe point found: __se_sys_open+0
        Found 1 probe_trace_events.
        Opening /sys/kernel/debug/tracing/README write=0
        Opening /sys/kernel/debug/tracing/kprobe_events write=1
        Parsing probe_events: p:probe/sys_open _text+4276888
        Group:probe Event:sys_open probe:p
        Writing event: r:probe/sys_open__return _text+4276888
        Added new event:
          probe:sys_open__return (on sys_open%return)
        ...
      Reported-by: default avatarAneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarSandipan Das <sandipan@linux.ibm.com>
      Acked-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Fixes: 99e608b5 ("perf probe ppc64le: Fix probe location when using DWARF")
      Link: http://lkml.kernel.org/r/20180809161929.35058-1-sandipan@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6841830a
  12. 09 Sep, 2018 1 commit
  13. 05 Sep, 2018 4 commits