Skip to content
  1. Jun 23, 2017
  2. Jun 16, 2017
  3. Jun 15, 2017
  4. Jun 13, 2017
  5. Jun 12, 2017
    • Mickaël Salaün's avatar
      selftests: kselftest_harness: Fix compile warning · 34a048cc
      Mickaël Salaün authored
      
      
      Do not confuse the compiler with a semicolon preceding a block. Replace
      the semicolon with an empty block to avoid a warning:
      
        gcc -Wl,-no-as-needed -Wall -lpthread seccomp_bpf.c -o /.../linux/tools/testing/selftests/seccomp/seccomp_bpf
        In file included from seccomp_bpf.c:40:0:
        seccomp_bpf.c: In function ‘change_syscall’:
        ../kselftest_harness.h:558:2: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
          for (; _metadata->trigger;  _metadata->trigger = __bail(_assert))
          ^
        ../kselftest_harness.h:574:14: note: in expansion of macro ‘OPTIONAL_HANDLER’
         } while (0); OPTIONAL_HANDLER(_assert)
                      ^~~~~~~~~~~~~~~~
        ../kselftest_harness.h:440:2: note: in expansion of macro ‘__EXPECT’
          __EXPECT(expected, seen, ==, 0)
          ^~~~~~~~
        seccomp_bpf.c:1313:2: note: in expansion of macro ‘EXPECT_EQ’
          EXPECT_EQ(0, ret);
          ^~~~~~~~~
        seccomp_bpf.c:1317:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
          {
          ^
      
      Signed-off-by: default avatarMickaël Salaün <mic@digikod.net>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Shuah Khan <shuahkh@osg.samsung.com>
      Cc: Will Drewry <wad@chromium.org>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarShuah Khan <shuahkh@osg.samsung.com>
      34a048cc
  6. Jun 07, 2017
  7. May 27, 2017
  8. May 25, 2017
  9. May 24, 2017
    • Ingo Molnar's avatar
      tools/include: Sync kernel ABI headers with tooling headers · 6e30437b
      Ingo Molnar authored
      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: default avatarIngo Molnar <mingo@kernel.org>
      6e30437b
    • Namhyung Kim's avatar
      perf tools: Put caller above callee in --children mode · 7111ffff
      Namhyung Kim authored
      
      
      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: default avatarNamhyung Kim <namhyung@kernel.org>
      Acked-by: default avatarJiri 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: default avatarIngo Molnar <mingo@kernel.org>
      7111ffff
    • Milian Wolff's avatar
      perf report: Do not drop last inlined frame · 4d53b9d5
      Milian Wolff authored
      
      
      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: default avatarMilian Wolff <milian.wolff@kdab.com>
      Signed-off-by: default avatarNamhyung 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: default avatarIngo Molnar <mingo@kernel.org>
      4d53b9d5
    • Milian Wolff's avatar
      perf report: Always honor callchain order for inlined nodes · 28071f51
      Milian Wolff authored
      
      
      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: default avatarMilian Wolff <milian.wolff@kdab.com>
      Signed-off-by: default avatarNamhyung 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: default avatarIngo Molnar <mingo@kernel.org>
      28071f51
    • Namhyung Kim's avatar
      perf script: Add --inline option for debugging · 325fbff5
      Namhyung Kim authored
      
      
      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: default avatarMilian Wolff <milian.wolff@kdab.com>
      Signed-off-by: default avatarNamhyung 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: default avatarIngo Molnar <mingo@kernel.org>
      325fbff5
    • Milian Wolff's avatar
      perf report: Fix off-by-one for non-activation frames · 1982ad48
      Milian Wolff authored
      
      
      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: default avatarMilian Wolff <milian.wolff@kdab.com>
      Signed-off-by: default avatarNamhyung 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: default avatarIngo Molnar <mingo@kernel.org>
      1982ad48
    • Milian Wolff's avatar
      perf report: Fix memory leak in addr2line when called by addr2inlines · b21cc978
      Milian Wolff authored
      
      
      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: default avatarMilian Wolff <milian.wolff@kdab.com>
      Signed-off-by: default avatarNamhyung 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: default avatarIngo Molnar <mingo@kernel.org>
      b21cc978
    • Milian Wolff's avatar
      perf report: Don't crash on invalid maps in `-g srcline` mode · 7d4df089
      Milian Wolff authored
      
      
      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: default avatarMilian Wolff <milian.wolff@kdab.com>
      [ Remove dependency from another change ]
      Signed-off-by: default avatarNamhyung 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: default avatarIngo Molnar <mingo@kernel.org>
      7d4df089
  10. May 19, 2017
    • Michael Ellerman's avatar
      selftests/powerpc: Fix TM resched DSCR test with some compilers · fe06fe86
      Michael Ellerman authored
      
      
      The tm-resched-dscr test has started failing sometimes, depending on
      what compiler it's built with, eg:
      
        test: tm_resched_dscr
        Check DSCR TM context switch: tm-resched-dscr: tm-resched-dscr.c:76: test_body: Assertion `rv' failed.
        !! child died by signal 6
      
      When it fails we see that the compiler doesn't initialise rv to 1 before
      entering the inline asm block. Although that's counter intuitive, it
      is allowed because we tell the compiler that the inline asm will write
      to rv (using "=r"), meaning the original value is irrelevant.
      
      Marking it as a read/write parameter would presumably work, but it seems
      simpler to fix it by setting the initial value of rv in the inline asm.
      
      Fixes: 96d01610 ("powerpc: Correct DSCR during TM context switch")
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Acked-by: default avatarMichael Neuling <mikey@neuling.org>
      fe06fe86
  11. May 18, 2017
Loading