2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-23 04:34:11 +08:00
Commit Graph

11179 Commits

Author SHA1 Message Date
Björn Töpel
7598f8bc13 perf probe: Fix probe definition for inlined functions
In commit 613f050d68 ("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: Björn Töpel <bjorn.topel@intel.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: stable@vger.kernel.org
Fixes: 613f050d68 ("perf probe: Fix to probe on gcc generated functions in modules")
Link: http://lkml.kernel.org/r/20170621164134.5701-1-bjorn.topel@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-22 16:08:09 -03:00
Logan Gunthorpe
07b0b22b3e NTB: ntb_test: fix bug printing ntb_perf results
The code mistakenly prints the local perf results for the remote test
so the script reports identical results for both directions. Fix this
by ensuring we print the remote result.

Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Fixes: a9c59ef774 ("ntb_test: Add a selftest script for the NTB subsystem")
Acked-by: Allen Hubbe <Allen.Hubbe@dell.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
2017-06-19 14:24:41 -04:00
Linus Torvalds
a1ff31d746 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf fixes from Thomas Gleixner:
 "Three fixes for the perf user space side:

   - Fix the probing of precise_ip level, which got broken recently for
     x86.

   - Unbreak the ARCH=x86_64 build

   - Report module before trying to unwind into the module code, which
     avoids broken stack frames displayed"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf unwind: Report module before querying isactivation in dwfl unwind
  perf tools: Fix build with ARCH=x86_64
  perf evsel: Fix probing of precise_ip level for default cycles event
2017-06-18 18:42:31 +09:00
Linus Torvalds
0cbf341508 Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull objtool fix from Thomas Gleixner:
 "A single fix which adds fortify_panic to the list of no return
  functions"

* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  objtool: Add fortify_panic as __noreturn function
2017-06-18 18:38:42 +09:00
Milian Wolff
9126cbbace perf unwind: Report module before querying isactivation in dwfl unwind
The PC returned by dwfl_frame_pc() may map into a not-yet-reported
module. We have to report it before we continue unwinding. But when we
query for the isactivation flag in dwfl_frame_pc, libdw will actually do
one more unwinding step internally which can then break and lead to
missed frames or broken stacks.

With libunwind we get e.g.:

~~~~~
  heaptrack_gui  2228 135073.400474:     613969 cycles:
	          108c8e [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	          1093bc [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	          109e7b QLocale::QLocale (/usr/lib/libQt5Core.so.5.8.0)
	          1470ff [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	          147f67 QSystemLocale::query (/usr/lib/libQt5Core.so.5.8.0)
	          109fbf QLocalePrivate::updateSystemPrivate (/usr/lib/libQt5Core.so.5.8.0)
	          10aa27 QLocale::QLocale (/usr/lib/libQt5Core.so.5.8.0)
	          1e02c3 [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	          2113bb [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	          211505 [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	          1b5df0 QFileInfo::exists (/usr/lib/libQt5Core.so.5.8.0)
	           92eb2 [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	           93423 [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	           93d2a QLibraryInfo::location (/usr/lib/libQt5Core.so.5.8.0)
	          2170af [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	          297c53 QCoreApplicationPrivate::init (/usr/lib/libQt5Core.so.5.8.0)
	           f7cde QGuiApplicationPrivate::init (/usr/lib/libQt5Gui.so.5.8.0)
	          1589e8 QApplicationPrivate::init (/usr/lib/libQt5Widgets.so.5.8.0)
	           78622 main (/home/milian/projects/compiled/other/bin/heaptrack_gui)
	           20439 __libc_start_main (/usr/lib/libc-2.25.so)
	           78299 _start (/home/milian/projects/compiled/other/bin/heaptrack_gui)

  heaptrack_gui  2228 135073.401156:     569521 cycles:
	          131633 QString::endsWith (/usr/lib/libQt5Core.so.5.8.0)
	          1a0701 QDir::cleanPath (/usr/lib/libQt5Core.so.5.8.0)
	          21b82d [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	          1b3727 QFileInfo::canonicalFilePath (/usr/lib/libQt5Core.so.5.8.0)
	          2780c7 QFactoryLoader::update (/usr/lib/libQt5Core.so.5.8.0)
	          279525 QFactoryLoader::QFactoryLoader (/usr/lib/libQt5Core.so.5.8.0)
	           e5bd0 QPlatformIntegrationFactory::create (/usr/lib/libQt5Gui.so.5.8.0)
	           f5a1c QGuiApplicationPrivate::createPlatformIntegration (/usr/lib/libQt5Gui.so.5.8.0)
	           f650c QGuiApplicationPrivate::createEventDispatcher (/usr/lib/libQt5Gui.so.5.8.0)
	          298524 QCoreApplicationPrivate::init (/usr/lib/libQt5Core.so.5.8.0)
	           f7cde QGuiApplicationPrivate::init (/usr/lib/libQt5Gui.so.5.8.0)
	          1589e8 QApplicationPrivate::init (/usr/lib/libQt5Widgets.so.5.8.0)
	           78622 main (/home/milian/projects/compiled/other/bin/heaptrack_gui)
	           20439 __libc_start_main (/usr/lib/libc-2.25.so)
	           78299 _start (/home/milian/projects/compiled/other/bin/heaptrack_gui)
~~~~~

Note the two frames 1589e8 and 78622 in the first sample. These are
missing when unwinding with libdw. The second sample's breakage is
more obvious:

~~~~~
  heaptrack_gui  2228 135073.400474:     613969 cycles:
	          108c8e [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	          1093bc [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	          109e7b QLocale::QLocale (/usr/lib/libQt5Core.so.5.8.0)
	          1470ff [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	          147f67 QSystemLocale::query (/usr/lib/libQt5Core.so.5.8.0)
	          109fbf QLocalePrivate::updateSystemPrivate (/usr/lib/libQt5Core.so.5.8.0)
	          10aa27 QLocale::QLocale (/usr/lib/libQt5Core.so.5.8.0)
	          1e02c3 [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	          2113bb [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	          211505 [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	          1b5df0 QFileInfo::exists (/usr/lib/libQt5Core.so.5.8.0)
	           92eb2 [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	           93423 [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	           93d2a QLibraryInfo::location (/usr/lib/libQt5Core.so.5.8.0)
	          2170af [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	          297c53 QCoreApplicationPrivate::init (/usr/lib/libQt5Core.so.5.8.0)
	           f7cde QGuiApplicationPrivate::init (/usr/lib/libQt5Gui.so.5.8.0)
	           20439 __libc_start_main (/usr/lib/libc-2.25.so)
	           78299 _start (/home/milian/projects/compiled/other/bin/heaptrack_gui)

heaptrack_gui  2228 135073.401156:     569521 cycles:
	          131633 QString::endsWith (/usr/lib/libQt5Core.so.5.8.0)
	          1a0701 QDir::cleanPath (/usr/lib/libQt5Core.so.5.8.0)
	          21b82d [unknown] (/usr/lib/libQt5Core.so.5.8.0)
	          1b3727 QFileInfo::canonicalFilePath (/usr/lib/libQt5Core.so.5.8.0)
	          2780c7 QFactoryLoader::update (/usr/lib/libQt5Core.so.5.8.0)
	          279525 QFactoryLoader::QFactoryLoader (/usr/lib/libQt5Core.so.5.8.0)
	           e5bd0 QPlatformIntegrationFactory::create (/usr/lib/libQt5Gui.so.5.8.0)
	          723dbf [unknown] ([unknown])
~~~~~

This patch fixes this issue and the libdw unwinder mimicks the libunwind
behavior more closely.

Signed-off-by: Milian Wolff <milian.wolff@kdab.com>
Acked-by: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20170602143753.16907-2-milian.wolff@kdab.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-16 14:37:30 -03:00
Kees Cook
92b0a1416b objtool: Add fortify_panic as __noreturn function
CONFIG_FORTIFY_SOURCE=y implements fortify_panic() as a __noreturn function,
so objtool needs to know about it too.

Suggested-by: Daniel Micay <danielmicay@gmail.com>
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1497532835-32704-1-git-send-email-jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-16 10:50:59 +02:00
Linus Torvalds
a090bd4ff8 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
Pull networking fixes from David Miller:

 1) The netlink attribute passed in to dev_set_alias() is not
    necessarily NULL terminated, don't use strlcpy() on it. From
    Alexander Potapenko.

 2) Fix implementation of atomics in arm64 bpf JIT, from Daniel
    Borkmann.

 3) Correct the release of netdevs and driver private data in certain
    circumstances.

 4) Sanitize netlink message length properly in decnet, from Mateusz
    Jurczyk.

 5) Don't leak kernel data in rtnl_fill_vfinfo() netlink blobs. From
    Yuval Mintz.

 6) Hash secret is never initialized in ipv6 ILA translation code, from
    Arnd Bergmann. I guess those clang warnings about unused inline
    functions are useful for something!

 7) Fix endian selection in bpf_endian.h, from Daniel Borkmann.

 8) Sanitize sockaddr length before dereferncing any fields in AF_UNIX
    and CAIF. From Mateusz Jurczyk.

 9) Fix timestamping for GMAC3 chips in stmmac driver, from Mario
    Molitor.

10) Do not leak netdev on dev_alloc_name() errors in mac80211, from
    Johannes Berg.

11) Fix locking in sctp_for_each_endpoint(), from Xin Long.

12) Fix wrong memset size on 32-bit in snmp6, from Christian Perle.

13) Fix use after free in ip_mc_clear_src(), from WANG Cong.

14) Fix regressions caused by ICMP rate limiting changes in 4.11, from
    Jesper Dangaard Brouer.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (91 commits)
  i40e: Fix a sleep-in-atomic bug
  net: don't global ICMP rate limit packets originating from loopback
  net/act_pedit: fix an error code
  net: update undefined ->ndo_change_mtu() comment
  net_sched: move tcf_lock down after gen_replace_estimator()
  caif: Add sockaddr length check before accessing sa_family in connect handler
  qed: fix dump of context data
  qmi_wwan: new Telewell and Sierra device IDs
  net: phy: Fix MDIO_THUNDER dependencies
  netconsole: Remove duplicate "netconsole: " logging prefix
  igmp: acquire pmc lock for ip_mc_clear_src()
  r8152: give the device version
  net: rps: fix uninitialized symbol warning
  mac80211: don't send SMPS action frame in AP mode when not needed
  mac80211/wpa: use constant time memory comparison for MACs
  mac80211: set bss_info data before configuring the channel
  mac80211: remove 5/10 MHz rate code from station MLME
  mac80211: Fix incorrect condition when checking rx timestamp
  mac80211: don't look at the PM bit of BAR frames
  i40e: fix handling of HW ATR eviction
  ...
2017-06-15 18:09:47 +09:00
Jiada Wang
7a759cd8e8 perf tools: Fix build with ARCH=x86_64
With commit: 0a943cb10c (tools build: Add HOSTARCH Makefile variable)
when building for ARCH=x86_64, ARCH=x86_64 is passed to perf instead of
ARCH=x86, so the perf build process searchs header files from
tools/arch/x86_64/include, which doesn't exist.

The following build failure is seen:

  In file included from util/event.c:2:0:
    tools/include/uapi/linux/mman.h:4:27: fatal error: uapi/asm/mman.h: No such file or directory
    compilation terminated.

Fix this issue by using SRCARCH instead of ARCH in perf, just like the
main kernel Makefile and tools/objtool's.

Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Eugeniu Rosca <erosca@de.adit-jv.com>
Cc: Jan Stancek <jstancek@redhat.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Cc: Rui Teng <rui.teng@linux.vnet.ibm.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes: 0a943cb10c ("tools build: Add HOSTARCH Makefile variable")
Link: http://lkml.kernel.org/r/1491793357-14977-2-git-send-email-jiada_wang@mentor.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-14 15:44:29 -03:00
Arnaldo Carvalho de Melo
7a1ac110c2 perf evsel: Fix probing of precise_ip level for default cycles event
Since commit 18e7a45af9 ("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: Thomas-Mich Richter <tmricht@linux.vnet.ibm.com>
Acked-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Acked-by: Jiri 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: 18e7a45af9 ("perf/x86: Reject non sampling events with precise_ip")
Link: http://lkml.kernel.org/n/tip-yv6nnkl7tzqocrm0hl3x7vf1@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-14 15:44:29 -03:00
Daniel Borkmann
78a5a93c1e bpf, tests: fix endianness selection
I noticed that test_l4lb was failing in selftests:

  # ./test_progs
  test_pkt_access:PASS:ipv4 77 nsec
  test_pkt_access:PASS:ipv6 44 nsec
  test_xdp:PASS:ipv4 2933 nsec
  test_xdp:PASS:ipv6 1500 nsec
  test_l4lb:PASS:ipv4 377 nsec
  test_l4lb:PASS:ipv6 544 nsec
  test_l4lb:FAIL:stats 6297600000 200000
  test_tcp_estats:PASS: 0 nsec
  Summary: 7 PASSED, 1 FAILED

Tracking down the issue actually revealed that endianness selection
in bpf_endian.h is broken when compiled with clang with bpf target.
test_pkt_access.c, test_l4lb.c is compiled with __BYTE_ORDER as
__BIG_ENDIAN, test_xdp.c as __LITTLE_ENDIAN! test_l4lb noticeably
fails, because the test accounts bytes via bpf_ntohs(ip6h->payload_len)
and bpf_ntohs(iph->tot_len), and compares them against a defined
value and given a wrong endianness, the test outcome is different,
of course.

Turns out that there are actually two bugs: i) when we do __BYTE_ORDER
comparison with __LITTLE_ENDIAN/__BIG_ENDIAN, then depending on the
include order we see different outcomes. Reason is that __BYTE_ORDER
is undefined due to missing endian.h include. Before we include the
asm/byteorder.h (e.g. through linux/in.h), then __BYTE_ORDER equals
__LITTLE_ENDIAN since both are undefined, after the include which
correctly pulls in linux/byteorder/little_endian.h, __LITTLE_ENDIAN
is defined, but given __BYTE_ORDER is still undefined, we match on
__BYTE_ORDER equals to __BIG_ENDIAN since __BIG_ENDIAN is also
undefined at that point, sigh. ii) But even that would be wrong,
since when compiling the test cases with clang, one can select between
bpfeb and bpfel targets for cross compilation. Hence, we can also not
rely on what the system's endian.h provides, but we need to look at
the compiler's defined endianness. The compiler defines __BYTE_ORDER__,
and we can match __ORDER_LITTLE_ENDIAN__ and __ORDER_BIG_ENDIAN__,
which also reflects targets bpf (native), bpfel, bpfeb correctly,
thus really only rely on that. After patch:

  # ./test_progs
  test_pkt_access:PASS:ipv4 74 nsec
  test_pkt_access:PASS:ipv6 42 nsec
  test_xdp:PASS:ipv4 2340 nsec
  test_xdp:PASS:ipv6 1461 nsec
  test_l4lb:PASS:ipv4 400 nsec
  test_l4lb:PASS:ipv6 530 nsec
  test_tcp_estats:PASS: 0 nsec
  Summary: 7 PASSED, 0 FAILED

Fixes: 43bcf707cc ("bpf: fix _htons occurences in test_progs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08 16:17:29 -04:00
Namhyung Kim
b89fe63fba perf symbols: Kill dso__build_id_is_kmod()
The commit e7ee404757 ("perf symbols: Fix symbols searching for module
in buildid-cache") added the function to check kernel modules reside in
the build-id cache.  This was because there's no way to identify a DSO
which is actually a kernel module.  So it searched linkname of the file
and find ".ko" suffix.

But this does not work for compressed kernel modules and now such DSOs
hCcave correct symtab_type now.  So no need to check it anymore.  This
patch essentially reverts the commit.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170608073109.30699-10-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-08 15:39:34 -03:00
Namhyung Kim
c25ec42f84 perf symbols: Keep DSO->symtab_type after decompress
The symsrc__init() overwrites dso->symtab_type as symsrc->type in
dso__load_sym().  But for compressed kernel modules in the build-id
cache, it should have original symtab type to be decompressed as needed.

This fixes perf annotate to show disassembly of the function properly.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170608073109.30699-9-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-08 15:39:26 -03:00
Namhyung Kim
94df1040b1 perf tests: Decompress kernel module before objdump
If a kernel modules is compressed, it should be decompressed before
running objdump to parse binary data correctly.  This fixes a failure of
object code reading test for me.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170608073109.30699-8-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-08 15:39:19 -03:00
Namhyung Kim
8ba29adf9a perf tools: Consolidate error path in __open_dso()
On failure, it should free the 'name', so clean up the error path using
goto.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Suggested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170608073109.30699-7-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-08 15:39:13 -03:00
Namhyung Kim
1d6b3c9ba7 perf tools: Decompress kernel module when reading DSO data
Currently perf decompresses kernel modules when loading the symbol table
but it missed to do it when reading raw data.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170608073109.30699-6-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-08 15:39:07 -03:00
Namhyung Kim
3c84fd5304 perf annotate: Use dso__decompress_kmodule_path()
Convert open-coded decompress routine to use the function.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170608073109.30699-5-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-08 15:39:02 -03:00
Namhyung Kim
42b3fa6708 perf tools: Introduce dso__decompress_kmodule_{fd,path}
Move decompress_kmodule() to util/dso.c and split it into two functions
returning fd and (decompressed) file path.  The existing user only wants
the fd version but the path version will be used soon.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170608073109.30699-4-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-08 15:38:55 -03:00
Namhyung Kim
44ad6b8852 perf tools: Fix a memory leak in __open_dso()
The 'name' variable should be freed on the error path.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170608073109.30699-3-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-08 15:38:47 -03:00
Namhyung Kim
3619ef76b3 perf annotate: Fix symbolic link of build-id cache
The commit 6ebd2547dd ("perf annotate: Fix a bug following symbolic
link of a build-id file") changed to use dirname to follow the symlink.
But it only considers new-style build-id cache names so old names fail
on readlink() and force to use system path which might not available.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Taeung Song <treeze.taeung@gmail.com>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: kernel-team@lge.com
Fixes: 6ebd2547dd ("perf annotate: Fix a bug following symbolic link of a build-id file")
Link: http://lkml.kernel.org/r/20170608073109.30699-2-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-08 15:38:41 -03:00
SeongJae Park
14fc42fa1b perf script python: Remove dups in documentation examples
Few shell command examples in perf-script-python.txt has few nitpicks
include:

- tools/perf/scripts/python directory listing command is unnecessarily
  repeated.
- few examples contain additional information in command prompt
  unnecessarily and inconsistently.

This commit fixes them to enhance readability of the document.

Signed-off-by: SeongJae Park <sj38.park@gmail.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Tom Zanussi <tzanussi@gmail.com>
Fixes: cff68e5822 ("perf/scripts: Add perf-trace-python Documentation")
Link: http://lkml.kernel.org/r/20170530111827.21732-4-sj38.park@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-07 20:36:12 -03:00
SeongJae Park
1bf8d5a4a5 perf script python: Updated trace_unhandled() signature
Default function signature of trace_unhandled() got changed to include a
field dict, but its documentation, perf-script-python.txt has not been
updated.  Fix it.

Signed-off-by: SeongJae Park <sj38.park@gmail.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Pierre Tardy <tardyp@gmail.com>
Fixes: c02514850d ("perf scripts python: Give field dict to unhandled callback")
Link: http://lkml.kernel.org/r/20170530111827.21732-6-sj38.park@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-07 20:27:32 -03:00
SeongJae Park
26ddb8722d perf script python: Fix wrong code snippets in documentation
This commit fixes wrong code snippets for trace_begin() and trace_end()
function example definition.

Signed-off-by: SeongJae Park <sj38.park@gmail.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Tom Zanussi <tzanussi@gmail.com>
Fixes: cff68e5822 ("perf/scripts: Add perf-trace-python Documentation")
Link: http://lkml.kernel.org/r/20170530111827.21732-5-sj38.park@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-07 20:27:26 -03:00
SeongJae Park
34d4453dac perf script: Fix documentation errors
This commit fixes two errors in documents for perf-script-python and
perf-script-perl as below:

- /sys/kernel/debug/tracing events -> /sys/kernel/debug/tracing/events/
- trace_handled -> trace_unhandled

Signed-off-by: SeongJae Park <sj38.park@gmail.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Tom Zanussi <tzanussi@gmail.com>
Fixes: cff68e5822 ("perf/scripts: Add perf-trace-python Documentation")
Link: http://lkml.kernel.org/r/20170530111827.21732-3-sj38.park@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-07 20:27:20 -03:00
SeongJae Park
c76132dc51 perf script: Fix outdated comment for perf-trace-python
Script generated by the '--gen-script' option contains an outdated
comment. It mentions a 'perf-trace-python' document while it has been
renamed to 'perf-script-python'. Fix it.

Signed-off-by: SeongJae Park <sj38.park@gmail.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 133dc4c39c ("perf: Rename 'perf trace' to 'perf script'")
Link: http://lkml.kernel.org/r/20170530111827.21732-2-sj38.park@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-07 20:23:22 -03:00
SeongJae Park
d89269a89e perf probe: Fix examples section of documentation
An example in perf-probe documentation for pattern of function name
based probe addition is not providing example command for that case.

This commit fixes the example to give appropriate example command.

Signed-off-by: SeongJae Park <sj38.park@gmail.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Taeung Song <treeze.taeung@gmail.com>
Fixes: ee391de876 ("perf probe: Update perf probe document")
Link: http://lkml.kernel.org/r/20170507103642.30560-1-sj38.park@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-07 20:23:11 -03:00
Ingo Molnar
3e411b0ee7 perf/urgent fixes:
- Only print NMI watchdog hint in 'perf stat' when it is enabled (Andi Kleen)
 
 - Fix sys_mmap/sys_old_mmap shandling in s390 in 'perf trace' (Jiri Olsa)
 
 - Disable breakpoint signal tests in powerpc, that lacks the perf kernel
   glue to set breakpoint events and makes 'perf test' always fail (Jiri Olsa)
 
 - Fix 'perf annotate' for branch instruction with multiple operands (Kim Phillips)
 
 - Add missing powerpc triplet when disassembling with 'objdump' in 'perf
   annotate' (Kim Phillips)
 
 - Do not trow away partial unwound stacks when using libdw, making
   callchains produced with it similar to those produced when linked with
   the other DWARF unwind library supported in perf, libunwind (Milian Wolff)
 
 - Fixes to properly handle kernel modules when processing build-id meta
   events (Namhyung Kim)
 
 - Fix handling of compressed modules in the build-id cache (Namhyung Kim)
 
 - Fix 'perf annotate' failure when filename has special chars (Ravi Bangoria)
 
 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJZNvv8AAoJENZQFvNTUqpAyvsP/01nEOO/fcIo3IDaTNFUxpHN
 olGvfk4C0Nxh0Nvus4Clf2z1i5GpWmAPBJ8EJkVzx3dHM7r1KBH2KITOzUf5ifok
 JY9h2mHkGT7wGXme0NqlElWNk3LyKbLYirWCdyZ1ZIRCW/XftcZLbWZn+KMxPbbS
 +PouuSUzlpCUvCd3KpmiMZMY5BmTRIF+xOVoChXFvrdqP4tZcBjPqPXTDlVl+/sp
 9DtBARXAGDssEElhcNJi1XfXXwh/tf8AqQNV67WtUJZUTDQEBqRE8ctY1fek4+qm
 0EzQvVirVlV/NFB3llgQ64XfY+ehhUVMtx+Zdqf3+1D8j+ovR0m9mjsXPKfzPwS8
 ml49zWP5slr33OEhGIkkLxS2DQIisFz0PJ8C/tZrCqQS+oDPjJNiLb2u3hISmwdS
 n6HfMbrxyfqRQ5rFNUeo9EyHERAEZJFOEt6sBUDVfHsNdKBObGjUjWR4fKf8Bn3G
 UKgDdpAmYoZgd2fwmsXP2GcfZu9FBFAGFyfZRNNbwb11a0Ozb8KAqxm0Y1ETwbnj
 XOeFZ+pE4anoBJ0BzQpD8nYXfZFT9GLVa+v8VbRxnuVTg/Ccmf6UgWFkUZc7gxmL
 gT94HpEnsbCAg+JI+Z2S5KhdcjYM9GPCBxE1HtjxaJFv5iSc8S4PnrzuTTOGG3/T
 g+Mp4KKEyazvDHM/tt0S
 =Oasi
 -----END PGP SIGNATURE-----

Merge tag 'perf-urgent-for-mingo-4.12-20170606' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent

Pull perf/urgent fixes from Arnaldo Carvalho de Melo:

 - Only print NMI watchdog hint in 'perf stat' when it is enabled (Andi Kleen)

 - Fix sys_mmap/sys_old_mmap shandling in s390 in 'perf trace' (Jiri Olsa)

 - Disable breakpoint signal tests in powerpc, that lacks the perf kernel
   glue to set breakpoint events and makes 'perf test' always fail (Jiri Olsa)

 - Fix 'perf annotate' for branch instruction with multiple operands (Kim Phillips)

 - Add missing powerpc triplet when disassembling with 'objdump' in 'perf
   annotate' (Kim Phillips)

 - Do not trow away partial unwound stacks when using libdw, making
   callchains produced with it similar to those produced when linked with
   the other DWARF unwind library supported in perf, libunwind (Milian Wolff)

 - Fixes to properly handle kernel modules when processing build-id meta
  events (Namhyung Kim)

 - Fix handling of compressed modules in the build-id cache (Namhyung Kim)

 - Fix 'perf annotate' failure when filename has special chars (Ravi Bangoria)

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-07 17:50:19 +02:00
Milian Wolff
2538b9e245 perf report: Ensure the perf DSO mapping matches what libdw sees
In some situations the libdw unwinder stopped working properly.  I.e.
with libunwind we see:

~~~~~
heaptrack_gui  2228 135073.400112:     641314 cycles:
	            e8ed _dl_fixup (/usr/lib/ld-2.25.so)
	           15f06 _dl_runtime_resolve_sse_vex (/usr/lib/ld-2.25.so)
	           ed94c KDynamicJobTracker::KDynamicJobTracker (/home/milian/projects/compiled/kf5/lib64/libKF5KIOWidgets.so.5.35.0)
	           608f3 _GLOBAL__sub_I_kdynamicjobtracker.cpp (/home/milian/projects/compiled/kf5/lib64/libKF5KIOWidgets.so.5.35.0)
	            f199 call_init.part.0 (/usr/lib/ld-2.25.so)
	            f2a5 _dl_init (/usr/lib/ld-2.25.so)
	             db9 _dl_start_user (/usr/lib/ld-2.25.so)
~~~~~

But with libdw and without this patch this sample is not properly
unwound:

~~~~~
heaptrack_gui  2228 135073.400112:     641314 cycles:
	            e8ed _dl_fixup (/usr/lib/ld-2.25.so)
	           15f06 _dl_runtime_resolve_sse_vex (/usr/lib/ld-2.25.so)
	           ed94c KDynamicJobTracker::KDynamicJobTracker (/home/milian/projects/compiled/kf5/lib64/libKF5KIOWidgets.so.5.35.0)
~~~~~

Debug output showed me that libdw found a module for the last frame
address, but it thinks it belongs to /usr/lib/ld-2.25.so. This patch
double-checks what libdw sees and what perf knows. If the mappings
mismatch, we now report the elf known to perf. This fixes the situation
above, and the libdw unwinder produces the same stack as libunwind.

Signed-off-by: Milian Wolff <milian.wolff@kdab.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20170602143753.16907-1-milian.wolff@kdab.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-05 14:18:05 -03:00
Milian Wolff
5ea0416f51 perf report: Include partial stacks unwound with libdw
So far the whole stack was thrown away when any error occurred before
the maximum stack depth was unwound. This is actually a very common
scenario though. The stacks that got unwound so far are still
interesting. This removes a large chunk of differences when comparing
perf script output for libunwind and libdw perf unwinding.

E.g. with libunwind:

~~~~~
heaptrack_gui  2228 135073.388524:     479408 cycles:
        ffffffff811749ed perf_iterate_ctx ([kernel.kallsyms])
        ffffffff81181662 perf_event_mmap ([kernel.kallsyms])
        ffffffff811cf5ed mmap_region ([kernel.kallsyms])
        ffffffff811cfe6b do_mmap ([kernel.kallsyms])
        ffffffff811b0dca vm_mmap_pgoff ([kernel.kallsyms])
        ffffffff811cdb0c sys_mmap_pgoff ([kernel.kallsyms])
        ffffffff81033acb sys_mmap ([kernel.kallsyms])
        ffffffff81631d37 entry_SYSCALL_64_fastpath ([kernel.kallsyms])
                   192ca mmap64 (/usr/lib/ld-2.25.so)
                    59a9 _dl_map_object_from_fd (/usr/lib/ld-2.25.so)
                    83d0 _dl_map_object (/usr/lib/ld-2.25.so)
                    cda1 openaux (/usr/lib/ld-2.25.so)
                   1834f _dl_catch_error (/usr/lib/ld-2.25.so)
                    cfe2 _dl_map_object_deps (/usr/lib/ld-2.25.so)
                    3481 dl_main (/usr/lib/ld-2.25.so)
                   17387 _dl_sysdep_start (/usr/lib/ld-2.25.so)
                    4d37 _dl_start (/usr/lib/ld-2.25.so)
                     d87 _start (/usr/lib/ld-2.25.so)

heaptrack_gui  2228 135073.388677:     611329 cycles:
                   1a3e0 strcmp (/usr/lib/ld-2.25.so)
                    82b2 _dl_map_object (/usr/lib/ld-2.25.so)
                    cda1 openaux (/usr/lib/ld-2.25.so)
                   1834f _dl_catch_error (/usr/lib/ld-2.25.so)
                    cfe2 _dl_map_object_deps (/usr/lib/ld-2.25.so)
                    3481 dl_main (/usr/lib/ld-2.25.so)
                   17387 _dl_sysdep_start (/usr/lib/ld-2.25.so)
                    4d37 _dl_start (/usr/lib/ld-2.25.so)
                     d87 _start (/usr/lib/ld-2.25.so)
~~~~~

With libdw without this patch:

~~~~~
heaptrack_gui  2228 135073.388524:     479408 cycles:
        ffffffff811749ed perf_iterate_ctx ([kernel.kallsyms])
        ffffffff81181662 perf_event_mmap ([kernel.kallsyms])
        ffffffff811cf5ed mmap_region ([kernel.kallsyms])
        ffffffff811cfe6b do_mmap ([kernel.kallsyms])
        ffffffff811b0dca vm_mmap_pgoff ([kernel.kallsyms])
        ffffffff811cdb0c sys_mmap_pgoff ([kernel.kallsyms])
        ffffffff81033acb sys_mmap ([kernel.kallsyms])
        ffffffff81631d37 entry_SYSCALL_64_fastpath ([kernel.kallsyms])

heaptrack_gui  2228 135073.388677:     611329 cycles:
~~~~~

With this patch applied, the libdw unwinder will produce the same
output as the libunwind unwinder.

Signed-off-by: Milian Wolff <milian.wolff@kdab.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20170601210021.20046-1-milian.wolff@kdab.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-05 14:18:03 -03:00
Kim Phillips
6db47fdec7 perf annotate: Add missing powerpc triplet
On an Ubuntu xenial system, 'perf annotate' says to install powerpc
objdump on a system that already has binutils-powerpc-linux-gnu
installed.  Make perf aware of the missing triplet for the
powerpc-linux-gnu target.

Signed-off-by: Kim Phillips <kim.phillips@arm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/20170529142754.7fbfb1152fd8f2663de0ea70@arm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-05 14:18:02 -03:00
Jiri Olsa
598762cf91 perf test: Disable breakpoint signal tests for powerpc
The following tests are failing on powerpc:

  # perf test break
  18: Breakpoint overflow signal handler  : FAILED!
  19: Breakpoint overflow sampling        : FAILED!

The powerpc kenel so far does not have support to even create
instruction breakpoints using the perf event interface, so those tests
fail early in the config phase.

I added a '->is_supported()' callback to test struct to be able to
disable specific tests. It seems better than putting ifdefs directly to
the test array.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20170601205450.GA398@krava
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-05 14:18:01 -03:00
Namhyung Kim
a09935b878 perf symbols: Use correct filename for compressed modules in build-id cache
The decompress_kmodule() decompresses kernel modules in order to load
symbols from it.  In the DSO_BINARY_TYPE__BUILD_ID_CACHE case, it needs
the full file path to extract the file extension to determine the
decompression method.  But overwriting 'name' will fail the
decompression since it might point to a non-existing old file.

Instead, use dso->long_name for having the correct extension and use the
real filename to decompress.

In the DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE_COMP case, both names should
be the same.  This allows resolving symbols in the old modules.

Before:

  $ perf report -i perf.data.old | grep scsi_mod
     0.00%  cc1      [scsi_mod]    [k] 0x0000000000004aa6
     0.00%  as       [scsi_mod]    [k] 0x00000000000099e1
     0.00%  cc1      [scsi_mod]    [k] 0x0000000000009830
     0.00%  cc1      [scsi_mod]    [k] 0x0000000000001b8f

After:

     0.00%  cc1      [scsi_mod]    [k] scsi_handle_queue_ramp_up
     0.00%  as       [scsi_mod]    [k] scsi_sg_alloc
     0.00%  cc1      [scsi_mod]    [k] scsi_setup_cmnd
     0.00%  cc1      [scsi_mod]    [k] scsi_get_command

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170531120105.21731-3-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-05 14:17:59 -03:00
Namhyung Kim
6b335e8f54 perf symbols: Set module info when build-id event found
Like machine__findnew_module_dso(), it should set necessary info for
kernel modules to find symbol info from the file.  Factor out
dso__set_module_info() to do it.

This is needed for dso__needs_decompress() to detect such DSOs.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170531120105.21731-2-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-05 14:17:58 -03:00
Namhyung Kim
1deec1bd96 perf header: Set proper module name when build-id event found
When perf processes build-id event, it creates DSOs with the build-id.
But it didn't set the module short name (like '[module-name]') so when
processing a kernel mmap event of the module, it cannot found the DSO as
it only checks the short names.

That leads for perf to create a same DSO without the build-id info and
it'll lookup the system path even if the DSO is already in the build-id
cache.  After kernel was updated, perf cannot find the DSO  and cannot
show symbols in it anymore.

You can see this if you have an old data file (w/ old kernel version):

  $ perf report -i perf.data.old -v |& grep scsi_mod
  build id event received for /lib/modules/3.19.2-1-ARCH/kernel/drivers/scsi/scsi_mod.ko.gz : cafe1ce6ca13a98a5d9ed3425cde249e57a27fc1
  Failed to open /lib/modules/3.19.2-1-ARCH/kernel/drivers/scsi/scsi_mod.ko.gz, continuing without symbols
  ...

The second message didn't show the build-id.  With this patch:

  $ perf report -i perf.data.old -v |& grep scsi_mod
  build id event received for /lib/modules/3.19.2-1-ARCH/kernel/drivers/scsi/scsi_mod.ko.gz: cafe1ce6ca13a98a5d9ed3425cde249e57a27fc1
  /lib/modules/3.19.2-1-ARCH/kernel/drivers/scsi/scsi_mod.ko.gz with build id cafe1ce6ca13a98a5d9ed3425cde249e57a27fc1 not found, continuing without symbols
  ...

Now it shows the build-id but still cannot load the symbol table.  This
is a different problem which will be fixed in the next patch.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170531120105.21731-1-namhyung@kernel.org
[ Fix the build on older compilers (debian <= 8, fedora <= 21, etc) wrt kmod_path var init ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-05 14:16:49 -03:00
Andi Kleen
918c7b062a perf stat: Only print NMI watchdog hint when enabled
Only print the NMI watchdog hint when that watchdog it actually enabled.

This avoids printing these unnecessarily.

Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Link: http://lkml.kernel.org/n/tip-lnw7edxnqsphkmeew857wz1i@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-02 11:15:34 -03:00
Kim Phillips
b13bbeee5e perf annotate: Fix branch instruction with multiple operands
'perf annotate' is dropping the cr* fields from branch instructions.

Fix it by adding support to display branch instructions having
multiple operands.

Power Arch objdump of int_sqrt:

 20.36 | c0000000004d2694:   subf   r10,r10,r3
       | c0000000004d2698: v bgt    cr6,c0000000004d26a0 <int_sqrt+0x40>
  1.82 | c0000000004d269c:   mr     r3,r10
 29.18 | c0000000004d26a0:   mr     r10,r8
       | c0000000004d26a4: v bgt    cr7,c0000000004d26ac <int_sqrt+0x4c>
       | c0000000004d26a8:   mr     r10,r7

Power Arch Before Patch:

 20.36 |       subf   r10,r10,r3
       |     v bgt    40
  1.82 |       mr     r3,r10
 29.18 | 40:   mr     r10,r8
       |     v bgt    4c
       |       mr     r10,r7

Power Arch After patch:

 20.36 |       subf   r10,r10,r3
       |     v bgt    cr6,40
  1.82 |       mr     r3,r10
 29.18 | 40:   mr     r10,r8
       |     v bgt    cr7,4c
       |       mr     r10,r7

Also support AArch64 conditional branch instructions, which can
have up to three operands:

Aarch64 Non-simplified (raw objdump) view:

       │ffff0000083cd11c: ↑ cbz    w0, ffff0000083cd100 <security_fil▒
...
  4.44 │ffff000│083cd134: ↓ tbnz   w0, #26, ffff0000083cd190 <securit▒
...
  1.37 │ffff000│083cd144: ↓ tbnz   w22, #5, ffff0000083cd1a4 <securit▒
       │ffff000│083cd148:   mov    w19, #0x20000                   //▒
  1.02 │ffff000│083cd14c: ↓ tbz    w22, #2, ffff0000083cd1ac <securit▒
...
  0.68 │ffff000└──3cd16c: ↑ cbnz   w0, ffff0000083cd120 <security_fil▒

Aarch64 Simplified, before this patch:

       │    ↑ cbz    40
...
  4.44 │   │↓ tbnz   w0, #26, ffff0000083cd190 <security_file_permiss▒
...
  1.37 │   │↓ tbnz   w22, #5, ffff0000083cd1a4 <security_file_permiss▒
       │   │  mov    w19, #0x20000                   // #131072
  1.02 │   │↓ tbz    w22, #2, ffff0000083cd1ac <security_file_permiss▒
...
  0.68 │   └──cbnz   60

the cbz operand is missing, and the tbz doesn't get simplified processing
at all because the parsing function failed to match an address.

Aarch64 Simplified, After this patch applied:

       │    ↑ cbz    w0, 40
...
  4.44 │   │↓ tbnz   w0, #26, d0
...
  1.37 │   │↓ tbnz   w22, #5, e4
       │   │  mov    w19, #0x20000                   // #131072
  1.02 │   │↓ tbz    w22, #2, ec
...
  0.68 │   └──cbnz   w0, 60

Originally-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Tested-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Reported-by: Anton Blanchard <anton@samba.org>
Reported-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Kim Phillips <kim.phillips@arm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Taeung Song <treeze.taeung@gmail.com>
Link: http://lkml.kernel.org/r/20170601092959.f60d98912e8a1b66fd1e4c0e@arm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-01 14:48:36 -03:00
Jiri Olsa
54265664c1 perf trace: Add mmap alias for s390
The s390 architecture maps sys_mmap (nr 90) into sys_old_mmap.  For this
reason perf trace can't find the proper syscall event to get args format
from and displays it wrongly as 'continued'.

To fix that fill the "alias" field with "old_mmap" for trace's mmap record
to get the correct translation.

Before:
     0.042 ( 0.011 ms): vest/43052 fstat(statbuf: 0x3ffff89fd90                ) = 0
     0.042 ( 0.028 ms): vest/43052  ... [continued]: mmap()) = 0x3fffd6e2000
     0.072 ( 0.025 ms): vest/43052 read(buf: 0x3fffd6e2000, count: 4096        ) = 6

After:
     0.045 ( 0.011 ms): fstat(statbuf: 0x3ffff8a0930                           ) = 0
     0.057 ( 0.018 ms): mmap(arg: 0x3ffff8a0858                                ) = 0x3fffd14a000
     0.076 ( 0.025 ms): read(buf: 0x3fffd14a000, count: 4096                   ) = 6

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20170531113557.19175-1-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-01 10:13:21 -03:00
Linus Torvalds
6f68a6ae1f powerpc fixes for 4.12 #4
Fix running SPU programs on Cell, and a few other minor fixes.
 
 Thanks to:
   Alistair Popple, Jeremy Kerr, Michael Neuling, Nicholas Piggin.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJZKURPAAoJEFHr6jzI4aWAhckQAJxZZHt2OMbdNu0PxHdhZgxo
 +eSODIF0jvzBnYs/Pe9aqqrxuONxW+ioclyUIVYLUlHwLjCGf7x2Y5tJe0OmEff6
 ZOaUUcwECKw4cy2UJY6NCGv0nw/8INTDN5xPcQq9M8gExmX6plTmbnQg8Y10ONdQ
 LYu36GWyXF4ygblvLo7kXs8tuZYKozO6kPRqxiQ3zML2dOAyqWqPwpnoWSc6c7oR
 W+z/Vuxe3lTR+QHbfvnSpQhmdVi+WEnwFvgNmIise5R9Jd30Q1f1vES5E089ifmN
 b0Qi5/gkb6YWBkROvxTARFRdmU0/YPNDFWUsuyHJB/Nz1MnqqXx5X+5KpqqinPya
 azVoYW010x2zawm0aX+BF/WeH5ymsl++R84/aO8UR0fA2AIwEOQeLGWZvaZb8CMl
 9vd3NqCJ+diBhgCHiHp80pjD978bqt7Ls1nfbHhYTJ31HRT8Yz/ympWOhLE6rp+t
 kGR+UOHduaZWK3KHoE2WIoUFJuQMvRgFmjoy2G+YaK/PcUc8OA+90v1665fnbk+N
 wmZyAirP39gveHkHXDywqbEjN4CSMgsqrRW/KwPo0b4mf2m3rsIAshO9pBbZRv+P
 evhrAkCYRv5zGbGIYJ/TiEyball+8NQzxzoYmMzq62pjE27gyIe94Sqy80U4zyOC
 RqqUxflOBgMDC8Ufc30u
 =EM32
 -----END PGP SIGNATURE-----

Merge tag 'powerpc-4.12-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux

Pull powerpc fixes from Michael Ellerman:
 "Fix running SPU programs on Cell, and a few other minor fixes.

  Thanks to Alistair Popple, Jeremy Kerr, Michael Neuling, Nicholas
  Piggin"

* tag 'powerpc-4.12-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc: Add PPC_FEATURE userspace bits for SCV and DARN instructions
  powerpc/spufs: Fix hash faults for kernel regions
  powerpc: Fix booting P9 hash with CONFIG_PPC_RADIX_MMU=N
  powerpc/powernv/npu-dma.c: Fix opal_npu_destroy_context() call
  selftests/powerpc: Fix TM resched DSCR test with some compilers
2017-05-27 09:28:34 -07:00
Linus Torvalds
fac3fcae32 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf tooling fixes from Thomas Gleixner:

 - Synchronization of tools and kernel headers

 - A series of fixes for perf report addressing various failures:
    * Handle invalid maps proper
    * Plug a memory leak
    * Handle frames and callchain order correctly

 - Fixes for handling inlines and children mode

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  tools/include: Sync kernel ABI headers with tooling headers
  perf tools: Put caller above callee in --children mode
  perf report: Do not drop last inlined frame
  perf report: Always honor callchain order for inlined nodes
  perf script: Add --inline option for debugging
  perf report: Fix off-by-one for non-activation frames
  perf report: Fix memory leak in addr2line when called by addr2inlines
  perf report: Don't crash on invalid maps in `-g srcline` mode
2017-05-27 09:02:41 -07:00
Linus Torvalds
77d6465695 There's been a few memory issues found with ftrace.
One was simply a memory leak where not all was being freed that should
 have been in releasing a file pointer on set_graph_function.
 
 Then Thomas found that the ftrace trampolines were marked for read/write
 as well as execute. To shrink the possible attack surface, he added
 calls to set them to ro. Which also uncovered some other issues with
 freeing module allocated memory that had its permissions changed.
 
 Kprobes had a similar issue which is fixed and a selftest was added
 to trigger that issue again.
 -----BEGIN PGP SIGNATURE-----
 
 iQExBAABCAAbBQJZKOiVFBxyb3N0ZWR0QGdvb2RtaXMub3JnAAoJEMm5BfJq2Y3L
 vBoH/jxVozuAEVCv+Nbj6fhRxe4emjo0lZZb32EbEaSV/nUQGqHIZFdDQtbt+ld+
 sn06/BSMBI+L4BqLj1BCAW0e/zIn/4birIg53SX5jQwc3AlhUG7HS2d+RJZZCrp9
 Zofq9L6xZ4Hl2XjkPXqwEgtrwxQtkIPLlJqeYDJ6BVrlPfOPEwB7bfR7B684wiYT
 6h2Qo7f/ZQzgJ1sK8N2IjHEnAgE08KCYcj4IB4WHJk6SqQz3bv1Y00WBg2UQihVT
 TPPSVhYLnrSw53fxyALqZbHo2DvnQf1TnNadWxvSIpbvgm/T5GG60FDtvHgNfbwz
 yKuKAog+P9xBLkoAcfvODLY9O5s=
 =75TZ
 -----END PGP SIGNATURE-----

Merge tag 'trace-v4.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace

Pull ftrace fixes from Steven Rostedt:
 "There's been a few memory issues found with ftrace.

  One was simply a memory leak where not all was being freed that should
  have been in releasing a file pointer on set_graph_function.

  Then Thomas found that the ftrace trampolines were marked for
  read/write as well as execute. To shrink the possible attack surface,
  he added calls to set them to ro. Which also uncovered some other
  issues with freeing module allocated memory that had its permissions
  changed.

  Kprobes had a similar issue which is fixed and a selftest was added to
  trigger that issue again"

* tag 'trace-v4.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  x86/ftrace: Make sure that ftrace trampolines are not RWX
  x86/mm/ftrace: Do not bug in early boot on irqs_disabled in cpu_flush_range()
  selftests/ftrace: Add a testcase for many kprobe events
  kprobes/x86: Fix to set RWX bits correctly before releasing trampoline
  ftrace: Fix memory leak in ftrace_graph_release()
2017-05-27 08:30:30 -07:00
Ravi Bangoria
7b4500bc51 perf annotate: Fix failure when filename has special chars
When filename contains special chars, perf annotate fails
with an error:

  $ perf annotate --vmlinux ./vmlinux\(test\) --stdio native_safe_halt
    sh: -c: line 0: syntax error near unexpected token `('
    sh: -c: line 0: `objdump  --start-address=0xffffffff8184e840
    --stop-address=0xffffffff8184e848 -l -d --no-show-raw -S -C
    ./vmlinux(test) 2>/dev/null|grep -v ./vmlinux(test):|expand'

Fix it by surrounding filename in double quotes.

Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Cc: Adam Stylinski <adam.stylinski@etegent.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Taeung Song <treeze.taeung@gmail.com>
Link: http://lkml.kernel.org/r/20170505101417.2117-1-ravi.bangoria@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-05-27 10:10:18 -03:00
Masami Hiramatsu
bdd7e3d684 selftests/ftrace: Add a testcase for many kprobe events
Add a testcase to test kprobes via ftrace interface
with many concurrent kprobe events.

This tries to add many kprobe events (up to 256) on
kernel functions. To avoid making ftrace-based
kprobes (kprobes on fentry), it skips first N bytes
(on x86 N=5, on ppc or arm N=4) of function entry.
After that, it enables all those events, disable it,
and remove it.

Since the unoptimization buffer reclaiming will
be delayed, after removing events, it will wait
enough time.

Link: http://lkml.kernel.org/r/149577388470.11702.11832460851769204511.stgit@devbox

Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-05-26 22:37:00 -04:00
Daniel Borkmann
614d0d77b4 bpf: add various verifier test cases
This patch adds various verifier test cases:

1) A test case for the pruning issue when tracking alignment
   is used.
2) Various PTR_TO_MAP_VALUE_OR_NULL tests to make sure pointer
   arithmetic turns such register into UNKNOWN_VALUE type.
3) Test cases for the special treatment of LD_ABS/LD_IND to
   make sure verifier doesn't break calling convention here.
   Latter is needed, since f.e. arm64 JIT uses r1 - r5 for
   storing temporary data, so they really must be marked as
   NOT_INIT.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-05-25 13:44:28 -04:00
Ingo Molnar
6e30437bd4 tools/include: Sync kernel ABI headers with tooling headers
Sync (copy) the following v4.12 kernel headers to the tooling headers:

  arch/x86/include/asm/disabled-features.h:
  arch/x86/include/uapi/asm/kvm.h:
  arch/powerpc/include/uapi/asm/kvm.h:
  arch/s390/include/uapi/asm/kvm.h:
  arch/arm/include/uapi/asm/kvm.h:
  arch/arm64/include/uapi/asm/kvm.h:

   - 'struct kvm_sync_regs' got changed in an ABI-incompatible way,
     fortunately none of the (in-kernel) tooling relied on it

   - new KVM_DEV calls added

  arch/x86/include/asm/required-features.h:

   - 5-level paging hardware ABI detail added

  arch/x86/include/asm/cpufeatures.h:

   - new CPU feature added

  arch/x86/include/uapi/asm/vmx.h:

   - new VMX exit conditions

None of the changes requires fixes in the tooling source code.

This addresses the following warnings:

  Warning: include/uapi/linux/stat.h differs from kernel
  Warning: arch/x86/include/asm/disabled-features.h differs from kernel
  Warning: arch/x86/include/asm/required-features.h differs from kernel
  Warning: arch/x86/include/asm/cpufeatures.h differs from kernel
  Warning: arch/x86/include/uapi/asm/kvm.h differs from kernel
  Warning: arch/x86/include/uapi/asm/vmx.h differs from kernel
  Warning: arch/powerpc/include/uapi/asm/kvm.h differs from kernel
  Warning: arch/s390/include/uapi/asm/kvm.h differs from kernel
  Warning: arch/arm/include/uapi/asm/kvm.h differs from kernel
  Warning: arch/arm64/include/uapi/asm/kvm.h differs from kernel

Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Milian Wolff <milian.wolff@kdab.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yao Jin <yao.jin@linux.intel.com>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170524065721.j2mlch6bgk5klgbc@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-05-24 09:00:21 +02:00
Namhyung Kim
7111ffff60 perf tools: Put caller above callee in --children mode
The __hpp__sort_acc() sorts entries using callchain depth in order to
put callers above in children mode.  But it assumed the callchain order
was callee-first.  Now default (for children) is caller-first so the
order of entries is reverted.

For example, consider following case:

  $ perf report --no-children
  ..l
  # Overhead  Command  Shared Object        Symbol
  # ........  .......  ...................  ..........................
  #
      99.44%  a.out    a.out                [.] main
              |
              ---main
                 __libc_start_main
                 _start

Then children mode should show 'start' above '__libc_start_main' since
it's the caller (parent) of the __libc_start_main.  But it's reversed:

  # Children      Self  Command  Shared Object    Symbol
  # ........  ........  .......  ...............  .....................
  #
      99.61%     0.00%  a.out    libc-2.25.so     [.] __libc_start_main
      99.61%     0.00%  a.out    a.out            [.] _start
      99.54%    99.44%  a.out    a.out            [.] main

This patch fixes it.

  # Children      Self  Command  Shared Object    Symbol
  # ........  ........  .......  ...............  .....................
  #
      99.61%     0.00%  a.out    a.out            [.] _start
      99.61%     0.00%  a.out    libc-2.25.so     [.] __libc_start_main
      99.54%    99.44%  a.out    a.out            [.] main

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Milian Wolff <milian.wolff@kdab.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yao Jin <yao.jin@linux.intel.com>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170524062129.32529-8-namhyung@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-05-24 08:41:49 +02:00
Milian Wolff
4d53b9d546 perf report: Do not drop last inlined frame
The very last inlined frame, i.e. the one furthest away from the
non-inlined frame, was silently dropped. This is apparent when
comparing the output of `perf script` and `addr2line`:

~~~~~~
  $ perf script --inline
  ...
  a.out 26722 80836.309329:      72425 cycles:
                     21561 __hypot_finite (/usr/lib/libm-2.25.so)
                      ace3 hypot (/usr/lib/libm-2.25.so)
                       a4a main (a.out)
                           std::abs<double>
                           std::_Norm_helper<true>::_S_do_it<double>
                           std::norm<double>
                           main
                     20510 __libc_start_main (/usr/lib/libc-2.25.so)
                       bd9 _start (a.out)

  $ addr2line -a -f -i -e /tmp/a.out a4a | c++filt
  0x0000000000000a4a
  std::__complex_abs(doublecomplex )
  /usr/include/c++/6.3.1/complex:589
  double std::abs<double>(std::complex<double> const&)
  /usr/include/c++/6.3.1/complex:597
  double std::_Norm_helper<true>::_S_do_it<double>(std::complex<double> const&)
  /usr/include/c++/6.3.1/complex:654
  double std::norm<double>(std::complex<double> const&)
  /usr/include/c++/6.3.1/complex:664
  main
  /tmp/inlining.cpp:14
~~~~~

Note how `std::__complex_abs` is missing from the `perf script`
output. This is similarly showing up in `perf report`. The patch
here fixes this issue, and the output becomes:

~~~~~
  a.out 26722 80836.309329:      72425 cycles:
                     21561 __hypot_finite (/usr/lib/libm-2.25.so)
                      ace3 hypot (/usr/lib/libm-2.25.so)
                       a4a main (a.out)
                           std::__complex_abs
                           std::abs<double>
                           std::_Norm_helper<true>::_S_do_it<double>
                           std::norm<double>
                           main
                     20510 __libc_start_main (/usr/lib/libc-2.25.so)
                       bd9 _start (a.out)
~~~~~

Signed-off-by: Milian Wolff <milian.wolff@kdab.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yao Jin <yao.jin@linux.intel.com>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170524062129.32529-7-namhyung@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-05-24 08:41:48 +02:00
Milian Wolff
28071f5183 perf report: Always honor callchain order for inlined nodes
So far, the inlined nodes where only reversed when we built perf
against libbfd. If that was not available, the addr2line fallback
code path was missing the inline_list__reverse call.

Now we always add the nodes in the correct order within
inline_list__append. This removes the need to reverse the list
and also ensures that all callers construct the list in the right
order.

Signed-off-by: Milian Wolff <milian.wolff@kdab.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yao Jin <yao.jin@linux.intel.com>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170524062129.32529-6-namhyung@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-05-24 08:41:48 +02:00
Namhyung Kim
325fbff51f perf script: Add --inline option for debugging
The --inline option is to show inlined functions in callchains.

For example:

  $ perf script
  a.out  5644 11611.467597:     309961 cycles:u:
                     790 main (/home/namhyung/tmp/perf/a.out)
                   20511 __libc_start_main (/usr/lib/libc-2.25.so)
                     8ba _start (/home/namhyung/tmp/perf/a.out)
  ...

  $ perf script --inline
  a.out  5644 11611.467597:     309961 cycles:u:
                     790 main (/home/namhyung/tmp/perf/a.out)
                         std::__detail::_Adaptor<std::linear_congruential_engine<unsigned long, 16807ul, 0ul, 2147483647ul>, double>::operator()
                         std::uniform_real_distribution<double>::operator()<std::linear_congruential_engine<unsigned long, 16807ul, 0ul, 2147483647ul> >
                         std::uniform_real_distribution<double>::operator()<std::linear_congruential_engine<unsigned long, 16807ul, 0ul, 2147483647ul> >
                         main
                   20511 __libc_start_main (/usr/lib/libc-2.25.so)
                     8ba _start (/home/namhyung/tmp/perf/a.out)
  ...

Reviewed-and-tested-by: Milian Wolff <milian.wolff@kdab.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jin Yao <yao.jin@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Milian Wolff <milian.wolff@kdab.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170524062129.32529-5-namhyung@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-05-24 08:41:48 +02:00
Milian Wolff
1982ad48fc perf report: Fix off-by-one for non-activation frames
As the documentation for dwfl_frame_pc says, frames that
are no activation frames need to have their program counter
decremented by one to properly find the function of the caller.

This fixes many cases where perf report currently attributes
the cost to the next line. I.e. I have code like this:

~~~~~~~~~~~~~~~
  #include <thread>
  #include <chrono>

  using namespace std;

  int main()
  {
    this_thread::sleep_for(chrono::milliseconds(1000));
    this_thread::sleep_for(chrono::milliseconds(100));
    this_thread::sleep_for(chrono::milliseconds(10));

    return 0;
  }
~~~~~~~~~~~~~~~

Now compile and record it:

~~~~~~~~~~~~~~~
  g++ -std=c++11 -g -O2 test.cpp
  echo 1 | sudo tee /proc/sys/kernel/sched_schedstats
  perf record \
    --event sched:sched_stat_sleep \
    --event sched:sched_process_exit \
    --event sched:sched_switch --call-graph=dwarf \
    --output perf.data.raw \
    ./a.out
  echo 0 | sudo tee /proc/sys/kernel/sched_schedstats
  perf inject --sched-stat --input perf.data.raw --output perf.data
~~~~~~~~~~~~~~~

Before this patch, the report clearly shows the off-by-one issue.
Most notably, the last sleep invocation is incorrectly attributed
to the "return 0;" line:

~~~~~~~~~~~~~~~
  Overhead  Source:Line
  ........  ...........

   100.00%  core.c:0
            |
            ---__schedule core.c:0
               schedule
               do_nanosleep hrtimer.c:0
               hrtimer_nanosleep
               sys_nanosleep
               entry_SYSCALL_64_fastpath .tmp_entry_64.o:0
               __nanosleep_nocancel .:0
               std::this_thread::sleep_for<long, std::ratio<1l, 1000l> > thread:323
               |
               |--90.08%--main test.cpp:9
               |          __libc_start_main
               |          _start
               |
               |--9.01%--main test.cpp:10
               |          __libc_start_main
               |          _start
               |
                --0.91%--main test.cpp:13
                          __libc_start_main
                          _start
~~~~~~~~~~~~~~~

With this patch here applied, the issue is fixed. The report becomes
much more usable:

~~~~~~~~~~~~~~~
  Overhead  Source:Line
  ........  ...........

   100.00%  core.c:0
            |
            ---__schedule core.c:0
               schedule
               do_nanosleep hrtimer.c:0
               hrtimer_nanosleep
               sys_nanosleep
               entry_SYSCALL_64_fastpath .tmp_entry_64.o:0
               __nanosleep_nocancel .:0
               std::this_thread::sleep_for<long, std::ratio<1l, 1000l> > thread:323
               |
               |--90.08%--main test.cpp:8
               |          __libc_start_main
               |          _start
               |
               |--9.01%--main test.cpp:9
               |          __libc_start_main
               |          _start
               |
                --0.91%--main test.cpp:10
                          __libc_start_main
                          _start
~~~~~~~~~~~~~~~

Similarly it works for signal frames:

~~~~~~~~~~~~~~~
  __noinline void bar(void)
  {
    volatile long cnt = 0;

    for (cnt = 0; cnt < 100000000; cnt++);
  }

  __noinline void foo(void)
  {
    bar();
  }

  void sig_handler(int sig)
  {
    foo();
  }

  int main(void)
  {
    signal(SIGUSR1, sig_handler);
    raise(SIGUSR1);

    foo();
    return 0;
  }
~~~~~~~~~~~~~~~~

Before, the report wrongly points to `signal.c:29` after raise():

~~~~~~~~~~~~~~~~
  $ perf report --stdio --no-children -g srcline -s srcline
  ...
   100.00%  signal.c:11
            |
            ---bar signal.c:11
               |
               |--50.49%--main signal.c:29
               |          __libc_start_main
               |          _start
               |
                --49.51%--0x33a8f
                          raise .:0
                          main signal.c:29
                          __libc_start_main
                          _start
~~~~~~~~~~~~~~~~

With this patch in, the issue is fixed and we instead get:

~~~~~~~~~~~~~~~~
   100.00%  signal   signal            [.] bar
            |
            ---bar signal.c:11
               |
               |--50.49%--main signal.c:29
               |          __libc_start_main
               |          _start
               |
                --49.51%--0x33a8f
                          raise .:0
                          main signal.c:27
                          __libc_start_main
                          _start
~~~~~~~~~~~~~~~~

Note how this patch fixes this issue for both unwinding methods, i.e.
both dwfl and libunwind. The former case is straight-forward thanks
to dwfl_frame_pc(). For libunwind, we replace the functionality via
unw_is_signal_frame() for any but the very first frame.

Signed-off-by: Milian Wolff <milian.wolff@kdab.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yao Jin <yao.jin@linux.intel.com>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170524062129.32529-4-namhyung@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-05-24 08:41:48 +02:00
Milian Wolff
b21cc97810 perf report: Fix memory leak in addr2line when called by addr2inlines
When a filename was found in addr2line it was duplicated via strdup()
but never freed. Now we pass NULL and handle this gracefully in
addr2line.

Detected by Valgrind:

  ==16331== 1,680 bytes in 21 blocks are definitely lost in loss record 148 of 220
  ==16331==    at 0x4C2AF1F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
  ==16331==    by 0x672FA69: strdup (in /usr/lib/libc-2.25.so)
  ==16331==    by 0x52769F: addr2line (srcline.c:256)
  ==16331==    by 0x52769F: addr2inlines (srcline.c:294)
  ==16331==    by 0x52769F: dso__parse_addr_inlines (srcline.c:502)
  ==16331==    by 0x574D7A: inline__fprintf (hist.c:41)
  ==16331==    by 0x574D7A: ipchain__fprintf_graph (hist.c:147)
  ==16331==    by 0x57518A: __callchain__fprintf_graph (hist.c:212)
  ==16331==    by 0x5753CF: callchain__fprintf_graph.constprop.6 (hist.c:337)
  ==16331==    by 0x57738E: hist_entry__fprintf (hist.c:628)
  ==16331==    by 0x57738E: hists__fprintf (hist.c:882)
  ==16331==    by 0x44A20F: perf_evlist__tty_browse_hists (builtin-report.c:399)
  ==16331==    by 0x44A20F: report__browse_hists (builtin-report.c:491)
  ==16331==    by 0x44A20F: __cmd_report (builtin-report.c:624)
  ==16331==    by 0x44A20F: cmd_report (builtin-report.c:1054)
  ==16331==    by 0x4A49CE: run_builtin (perf.c:296)
  ==16331==    by 0x4A4CC0: handle_internal_command (perf.c:348)
  ==16331==    by 0x434371: run_argv (perf.c:392)
  ==16331==    by 0x434371: main (perf.c:530)

Signed-off-by: Milian Wolff <milian.wolff@kdab.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yao Jin <yao.jin@linux.intel.com>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170524062129.32529-3-namhyung@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-05-24 08:41:48 +02:00
Milian Wolff
7d4df089d7 perf report: Don't crash on invalid maps in -g srcline mode
I just hit a segfault when doing `perf report -g srcline`.
Valgrind pointed me at this code as the culprit:

  ==8359== Invalid read of size 8
  ==8359==    at 0x3096D9: map__rip_2objdump (map.c:430)
  ==8359==    by 0x2FC1A3: match_chain_srcline (callchain.c:645)
  ==8359==    by 0x2FC1A3: match_chain (callchain.c:700)
  ==8359==    by 0x2FC1A3: append_chain (callchain.c:895)
  ==8359==    by 0x2FC1A3: append_chain_children (callchain.c:846)
  ==8359==    by 0x2FF719: callchain_append (callchain.c:944)
  ==8359==    by 0x2FF719: hist_entry__append_callchain (callchain.c:1058)
  ==8359==    by 0x32FA06: iter_add_single_cumulative_entry (hist.c:908)
  ==8359==    by 0x33195C: hist_entry_iter__add (hist.c:1050)
  ==8359==    by 0x258F65: process_sample_event (builtin-report.c:204)
  ==8359==    by 0x30D60C: perf_session__deliver_event (session.c:1310)
  ==8359==    by 0x30D60C: ordered_events__deliver_event (session.c:119)
  ==8359==    by 0x310D12: __ordered_events__flush (ordered-events.c:210)
  ==8359==    by 0x310D12: ordered_events__flush.part.3 (ordered-events.c:277)
  ==8359==    by 0x30DD3C: perf_session__process_user_event (session.c:1349)
  ==8359==    by 0x30DD3C: perf_session__process_event (session.c:1475)
  ==8359==    by 0x30FC3C: __perf_session__process_events (session.c:1867)
  ==8359==    by 0x30FC3C: perf_session__process_events (session.c:1921)
  ==8359==    by 0x25A985: __cmd_report (builtin-report.c:575)
  ==8359==    by 0x25A985: cmd_report (builtin-report.c:1054)
  ==8359==    by 0x2B9A80: run_builtin (perf.c:296)
  ==8359==  Address 0x70 is not stack'd, malloc'd or (recently) free'd

This patch fixes the issue.

Signed-off-by: Milian Wolff <milian.wolff@kdab.com>
[ Remove dependency from another change ]
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yao Jin <yao.jin@linux.intel.com>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170524062129.32529-2-namhyung@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-05-24 08:41:47 +02:00