1. 20 9月, 2013 2 次提交
    • V
      tools lib lk: Uninclude linux/magic.h in debugfs.c · ce7eebe5
      Vinson Lee 提交于
      The compilation only looks for linux/magic.h from the default include
      paths, which does not include the source tree. This results in a build
      error if linux/magic.h is not available or not installed.
      
      For example, this build error occurs on CentOS 5.
      
      $ make -C tools/lib/lk V=1
      [...]
      gcc -o debugfs.o -c -ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6
      -D_FORTIFY_SOURCE=2 -Wbad-function-cast -Wdeclaration-after-statement
      -Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations
      -Wmissing-prototypes -Wnested-externs -Wno-system-headers
      -Wold-style-definition -Wpacked -Wredundant-decls -Wshadow
      -Wstrict-aliasing=3 -Wstrict-prototypes -Wswitch-default -Wswitch-enum
      -Wundef -Wwrite-strings -Wformat  -fPIC  -D_LARGEFILE64_SOURCE
      -D_FILE_OFFSET_BITS=64 debugfs.c
      debugfs.c:8:25: error: linux/magic.h: No such file or directory
      
      The only symbol from linux/magic.h needed by debugfs.c is DEBUGFS_MAGIC,
      and that is already defined in debugfs.h. linux/magic.h isn't providing
      any extra symbols and can unincluded. This is similar to the approach by
      perf, which has its own magic.h wrapper at
      tools/perf/util/include/linux/magic.h
      Signed-off-by: NVinson Lee <vlee@twitter.com>
      Acked-by: NBorislav Petkov <bp@suse.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Vinson Lee <vlee@freedesktop.org>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/1379546200-17028-1-git-send-email-vlee@freedesktop.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ce7eebe5
    • I
      perf tools: Fix old GCC build error in trace-event-parse.c:parse_proc_kallsyms() · 0f965429
      Ingo Molnar 提交于
      Old GCC (4.1) does not see through the code flow of parse_proc_kallsyms()
      and gets confused about the status of 'fmt':
      
       util/trace-event-parse.c: In function ‘parse_proc_kallsyms’:
       util/trace-event-parse.c:189: warning: ‘fmt’ may be used uninitialized in this function
       make: *** [util/trace-event-parse.o] Error 1
      
      Help out GCC by initializing 'fmt' to NULL.
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20130912131649.GC23826@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0f965429
  2. 19 9月, 2013 7 次提交
    • M
      perf probe: Fix finder to find lines of given function · 0dbb1cac
      Masami Hiramatsu 提交于
      The commit ba28c59b fixed a declaration
      entry bug in probe_point_search_cb().  There are same bugs in line
      finder and call_probe_finder().  This introduces a new dwarf utility
      function to determine given DIE is a function definition, not
      declaration.
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Prashanth Nageshappa <prashanth@linux.vnet.ibm.com>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: yrl.pp-manager.tt@hitachi.com
      Link: http://lkml.kernel.org/r/20120423032435.8737.80064.stgit@localhost.localdomainSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0dbb1cac
    • A
      perf session: Check for SIGINT in more loops · 33e940a2
      Arnaldo Carvalho de Melo 提交于
      When processing big files we were not checking if session_done was set
      by the SIGINT signal handler, for instance in 'perf report'. Fix it.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-pyad42lgrtq7xhg2dpsoauq7@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      33e940a2
    • A
      perf tools: Fix compile with libelf without get_phdrnum · e955d5c4
      Adrian Hunter 提交于
      Add a feature check for get_phdrnum() and implement a replacement if it
      is not present.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1379080170-6608-1-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e955d5c4
    • A
      perf tools: Fix buildid cache handling of kallsyms with kcore · 5b6a42fc
      Adrian Hunter 提交于
      When kallsyms is used with kcore the dso long_name becomes the kcore
      file name.  That prevents the buildid cache from caching kallsyms.
      (There is no support at present for caching kcore).  Fix by changing it
      so that the kallsyms name is used in that case instead.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1379009959-28046-1-git-send-email-adrian.hunter@intel.com
      [ Kept 'struct foo' pointer as first parameter of foo__ prefixed functions ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5b6a42fc
    • A
      perf annotate: Fix objdump line parsing offset validation · 886b37ba
      Adrian Hunter 提交于
      When parsing lines from objdump a line containing source code starting
      with a numeric label is mistaken for a line of disassembly starting with
      a memory address.
      
      Current validation fails to recognise that the "memory address" is out
      of range and calculates an invalid offset which later causes this
      segfault:
      
      Program received signal SIGSEGV, Segmentation fault.
      0x0000000000457315 in disasm__calc_percent (notes=0xc98970, evidx=0, offset=143705, end=2127526177, path=0x7fffffffbf50)
          at util/annotate.c:631
      631				hits += h->addr[offset++];
      (gdb) bt
       #0  0x0000000000457315 in disasm__calc_percent (notes=0xc98970, evidx=0, offset=143705, end=2127526177, path=0x7fffffffbf50)
          at util/annotate.c:631
       #1  0x00000000004d65e3 in annotate_browser__calc_percent (browser=0x7fffffffd130, evsel=0xa01da0) at ui/browsers/annotate.c:364
       #2  0x00000000004d7433 in annotate_browser__run (browser=0x7fffffffd130, evsel=0xa01da0, hbt=0x0) at ui/browsers/annotate.c:672
       #3  0x00000000004d80c9 in symbol__tui_annotate (sym=0xc989a0, map=0xa02660, evsel=0xa01da0, hbt=0x0) at ui/browsers/annotate.c:962
       #4  0x00000000004d7aa0 in hist_entry__tui_annotate (he=0xdf73f0, evsel=0xa01da0, hbt=0x0) at ui/browsers/annotate.c:823
       #5  0x00000000004dd648 in perf_evsel__hists_browse (evsel=0xa01da0, nr_events=1, helpline=
          0x58b768 "For a higher level overview, try: perf report --sort comm,dso", ev_name=0xa02cd0 "cycles", left_exits=false, hbt=
          0x0, min_pcnt=0, env=0xa011e0) at ui/browsers/hists.c:1659
       #6  0x00000000004de372 in perf_evlist__tui_browse_hists (evlist=0xa01520, help=
          0x58b768 "For a higher level overview, try: perf report --sort comm,dso", hbt=0x0, min_pcnt=0, env=0xa011e0)
          at ui/browsers/hists.c:1950
       #7  0x000000000042cf6b in __cmd_report (rep=0x7fffffffd6c0) at builtin-report.c:581
       #8  0x000000000042e25d in cmd_report (argc=0, argv=0x7fffffffe4b0, prefix=0x0) at builtin-report.c:965
       #9  0x000000000041a0e1 in run_builtin (p=0x801548, argc=1, argv=0x7fffffffe4b0) at perf.c:319
       #10 0x000000000041a319 in handle_internal_command (argc=1, argv=0x7fffffffe4b0) at perf.c:376
       #11 0x000000000041a465 in run_argv (argcp=0x7fffffffe38c, argv=0x7fffffffe380) at perf.c:420
       #12 0x000000000041a707 in main (argc=1, argv=0x7fffffffe4b0) at perf.c:521
      
      After the fix is applied the symbol can be annotated showing the
      problematic line "1:      rep"
      
      copy_user_generic_string  /usr/lib/debug/lib/modules/3.9.10-100.fc17.x86_64/vmlinux
                   */
                  ENTRY(copy_user_generic_string)
                          CFI_STARTPROC
                          ASM_STAC
                          andl %edx,%edx
                    and    %edx,%edx
                          jz 4f
                    je     37
                          cmpl $8,%edx
                    cmp    $0x8,%edx
                          jb 2f           /* less than 8 bytes, go to byte copy loop */
                    jb     33
                          ALIGN_DESTINATION
                    mov    %edi,%ecx
                    and    $0x7,%ecx
                    je     28
                    sub    $0x8,%ecx
                    neg    %ecx
                    sub    %ecx,%edx
              1a:   mov    (%rsi),%al
                    mov    %al,(%rdi)
                    inc    %rsi
                    inc    %rdi
                    dec    %ecx
                    jne    1a
                          movl %edx,%ecx
              28:   mov    %edx,%ecx
                          shrl $3,%ecx
                    shr    $0x3,%ecx
                          andl $7,%edx
                    and    $0x7,%edx
                  1:      rep
      100.00        rep    movsq %ds:(%rsi),%es:(%rdi)
                          movsq
                  2:      movl %edx,%ecx
              33:   mov    %edx,%ecx
                  3:      rep
                    rep    movsb %ds:(%rsi),%es:(%rdi)
                          movsb
                  4:      xorl %eax,%eax
              37:   xor    %eax,%eax
                    data32 xchg %ax,%ax
                          ASM_CLAC
                          ret
                    retq
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1379009721-27667-1-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      886b37ba
    • I
      perf tools: Fill in new definitions for madvise()/mmap() flags · 456857bd
      Ingo Molnar 提交于
      builtin-trace.c started using various new syscall features not defined
      in the header files of older distros - resulting in build failures.
      
      Fill in the (ABI) constants if they are not defined.
      
      (There might be a better place to put this than builtin-trace.c, into a
      compat header or so.)
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-tip-commits@vger.kernel.org
      Link: http://lkml.kernel.org/r/20130912132900.GE23826@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      456857bd
    • I
      perf tools: Sharpen the libaudit dependencies test · 33cbbdcc
      Ingo Molnar 提交于
      There are older libaudit versions that don't have an
      audit_errno_to_name() method, resulting in a builtin-trace.c build
      error:
      
        builtin-trace.c: In function ‘trace__sys_exit’:
        builtin-trace.c:794: warning: implicit declaration of function ‘audit_errno_to_name’
      
      Expand the libaudit test to detect this.
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20130912132706.GD23826@gmail.com
      [ Fix the test by escaping the double quotes ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      33cbbdcc
  3. 18 9月, 2013 1 次提交
  4. 13 9月, 2013 1 次提交
    • P
      perf/x86/intel: Fix Silvermont offcore masks · 06c939c1
      Peter Zijlstra 提交于
      Fengguang Wu reported:
      
      > sparse warnings: (new ones prefixed by >>)
      >
      > >> arch/x86/kernel/cpu/perf_event_intel.c:901:9: sparse: constant 0x768005ffff is so big it is long
      > >> arch/x86/kernel/cpu/perf_event_intel.c:902:9: sparse: constant 0x768005ffff is so big it is long
      >
      > vim +901 arch/x86/kernel/cpu/perf_event_intel.c
      >
      >    895	 },
      >    896	};
      >    897
      >    898	static struct extra_reg intel_slm_extra_regs[] __read_mostly =
      >    899	{
      >    900		/* must define OFFCORE_RSP_X first, see intel_fixup_er() */
      >  > 901		INTEL_UEVENT_EXTRA_REG(0x01b7, MSR_OFFCORE_RSP_0, 0x768005ffff, RSP_0),
      >  > 902		INTEL_UEVENT_EXTRA_REG(0x02b7, MSR_OFFCORE_RSP_1, 0x768005ffff, RSP_1),
      >    903		EVENT_EXTRA_END
      >    904	};
      >    905
      
      Extend those constants to 64 bits.
      
      Reported-by: fengguang.wu@intel.com
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20130909112636.GQ31370@twins.programming.kicks-ass.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      06c939c1
  5. 12 9月, 2013 4 次提交
    • S
      perf/x86: Fix uncore PCI fixed counter handling · dbc33f70
      Stephane Eranian 提交于
      There was a bug in the handling of SNB-EP/IVB-EP uncore PCI
      fixed counters, e.g., IMC.
      
      It would cause erratic values to be returned for the IMC
      clockticks event. This was due to a bogus hwc->config value
      which was then written to PCI config space.
      
      The erratic values can be seen via:
      
        $ perf stat -a -C 0 -e uncore_imc_0/clockticks/ -I 1000 sleep 10
      
      The fixed counter has most fields marked as reserved with
      hw reset values of 0. Yet the kernel was defaulting to a
      hwc->config = ~0 and that was causing the issues.
      
      This patch sets the hwc->config values for fixed uncore event
      to 0. Now, the values of IMC clockticks is correct.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Cc: peterz@infradead.org
      Cc: zheng.z.yan@intel.com
      Link: http://lkml.kernel.org/r/20130909195350.GA17643@google.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      dbc33f70
    • O
      uprobes: Fix utask->depth accounting in handle_trampoline() · 878b5a6e
      Oleg Nesterov 提交于
      Currently utask->depth is simply the number of allocated/pending
      return_instance's in uprobe_task->return_instances list.
      
      handle_trampoline() should decrement this counter every time we
      handle/free an instance, but due to typo it does this only if
      ->chained == T. This means that in the likely case this counter
      is never decremented and the probed task can't report more than
      MAX_URETPROBE_DEPTH events.
      Reported-by: NMikhail Kulemin <Mikhail.Kulemin@ru.ibm.com>
      Reported-by: NHemant Kumar Shaw <hkshaw@linux.vnet.ibm.com>
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Acked-by: NAnton Arapov <anton@redhat.com>
      Cc: masami.hiramatsu.pt@hitachi.com
      Cc: srikar@linux.vnet.ibm.com
      Cc: systemtap@sourceware.org
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20130911154726.GA8093@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      878b5a6e
    • S
      perf/x86: Add constraint for IVB CYCLE_ACTIVITY:CYCLES_LDM_PENDING · 6113af14
      Stephane Eranian 提交于
      The IvyBridge event CYCLE_ACTIVITY:CYCLES_LDM_PENDING can only
      be measured on counters 0-3 when HT is off. When HT is on, you
      only have counters 0-3.
      
      If you program it on the eight counters for 1s on a 3GHz
      IVB laptop running a noploop, you see:
      
                 2 747 527 CYCLE_ACTIVITY:CYCLES_LDM_PENDING
                 2 747 527 CYCLE_ACTIVITY:CYCLES_LDM_PENDING
                 2 747 527 CYCLE_ACTIVITY:CYCLES_LDM_PENDING
                 2 747 527 CYCLE_ACTIVITY:CYCLES_LDM_PENDING
             3 280 563 608 CYCLE_ACTIVITY:CYCLES_LDM_PENDING
             3 280 563 608 CYCLE_ACTIVITY:CYCLES_LDM_PENDING
             3 280 563 608 CYCLE_ACTIVITY:CYCLES_LDM_PENDING
             3 280 563 608 CYCLE_ACTIVITY:CYCLES_LDM_PENDING
      
      Clearly the last 4 values are bogus.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Cc: peterz@infradead.org
      Cc: ak@linux.intel.com
      Cc: zheng.z.yan@intel.com
      Cc: dhsharp@google.com
      Link: http://lkml.kernel.org/r/20130911152222.GA28761@google.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      6113af14
    • I
      Merge tag 'perf-urgent-for-mingo' of... · e6d38183
      Ingo Molnar 提交于
      Merge tag 'perf-urgent-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent
      
      Pull perf/urgent fixes from Arnaldo Carvalho de Melo:
      
       * Handle perf.data files with no tracepoints in 'perf trace', fixing a
         segfault.
      
       * Fix up MMAP2 buffer space reservation, a problem that was caught via
         'perf test' consistency tests.
      
       * Add attr->mmap2 support in the tools, a patch that should've been merged
         together with the kernel counterpart:
      
           13d7a241 "perf: Add attr->mmap2 attribute to an event".
      
         Merging it allowed us to catch the MMAP buffer space reservation problem via
         'perf test'. From Stephane Eranian.
      
         The tools deals with older kernels by disabling this feature, resetting the
         perf_event_attr.mmap2 bit, when -EINVAL is returned by perf_event_open, just
         like with perf_event_attr.{sample_id_all,exclude_{guest,host}}.
      
         When such fallback happens the perf_missing_features.mmap2 flag is set to
         true and can be used by tooling that strictly needs this feature to check
         for its availability on the running kernel.
      
       * Make sure we can find PERF_SAMPLE_ID in the variable part of PERF_RECORD_
         ring buffer records in 'perf kvm', where direct manipulation of sample_type
         was being done.
      
         Fixed by making use of the perf_evlist__set_sample_bit() helper and by
         setting the evlist->id_pos in perf_evlist__open(), from Adrian Hunter.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      e6d38183
  6. 11 9月, 2013 2 次提交
    • A
      perf: Fix up MMAP2 buffer space reservation · d008d525
      Arnaldo Carvalho de Melo 提交于
      The ino_generation field was added in the PERF_RECORD_MMAP2 record in
      the 13d7a241 cset but no space for it was allocated, corrupting the
      PERF_FORMAT_{TIME,CPU,TID,etc} area (sample_type/sample_id_all), fix it.
      
      Detected with one of the regression tests done by 'perf test':
      
        [root@sandy ~]# perf test -v 7
         7: Validate PERF_RECORD_* events & perf_sample fields     :
        --- start ---
        61315294449606 0 PERF_RECORD_SAMPLE
        61315294453161 0 PERF_RECORD_SAMPLE
        61315294454441 0 PERF_RECORD_SAMPLE
        61315294455709 0 PERF_RECORD_SAMPLE
        61315295600899 0 PERF_RECORD_COMM: sleep:6500
        27917287430500 342521613 PERF_RECORD_MMAP2 6500/6500: [0x400000(0x7000) @ 0 00:1d 311442 9016]: /usr/bin/sleep
        MMAP2 going backwards in time, prev=61315295600899, curr=27917287430500
        MMAP2 with unexpected cpu, expected 0, got 342521613
        MMAP2 with unexpected pid, expected 6500, got 1701606191
        MMAP2 with unexpected tid, expected 6500, got 28773
        27917287430500 342561333 PERF_RECORD_MMAP2 6500/6500: [0x3b7e000000(0x223000) @ 0 00:1d 309186 9016]: /usr/lib64/ld-2.16.so
        MMAP2 with unexpected cpu, expected 0, got 342561333
        MMAP2 with unexpected pid, expected 6500, got 1932408369
        MMAP2 with unexpected tid, expected 6500, got 111
        27917287430500 342600095 PERF_RECORD_MMAP2 6500/6500: [0x7fffbd7dc000(0x1000) @ 0x7fffbd7dc000 00:00 0 0]: [vdso]
        MMAP2 with unexpected cpu, expected 0, got 342600095
        MMAP2 with unexpected pid, expected 6500, got 1935963739
        MMAP2 with unexpected tid, expected 6500, got 23919
        27917287430500 342882834 PERF_RECORD_MMAP2 6500/6500: [0x3b7e400000(0x3b8000) @ 0 00:1d 309187 9016]: /usr/lib64/libc-2.16.so
        MMAP2 with unexpected cpu, expected 0, got 342882834
        MMAP2 with unexpected pid, expected 6500, got 909192754
        MMAP2 with unexpected tid, expected 6500, got 7303982
        61316297195411 0 PERF_RECORD_EXIT(6500:6500):(6500:6500)
        ---- end ----
        Validate PERF_RECORD_* events & perf_sample fields: FAILED!
        [root@sandy ~]#
      
      After this patch:
      
        [root@sandy ~]# perf test 7
         7: Validate PERF_RECORD_* events & perf_sample fields     : Ok
        [root@sandy ~]#
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Acked-by: NStephane Eranian <eranian@google.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-heeuv986b8ha7whqg4o3he7c@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d008d525
    • S
      perf tools: Add attr->mmap2 support · 5c5e854b
      Stephane Eranian 提交于
      This patch adds support for the new PERF_RECORD_MMAP2 record type
      exposed by the kernel. This is an extended PERF_RECORD_MMAP record.
      
      It adds for each file-backed mapping the device major, minor number and
      the inode number and generation.
      
      This triplet uniquely identifies the source of a file-backed mapping. It
      can be used to detect identical virtual mappings between processes, for
      instance.
      
      The patch will prefer MMAP2 over MMAP.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1377079825-19057-3-git-send-email-eranian@google.com
      [ Cope with 314add6b "Change machine__findnew_thread() to set thread pid",
        fix 'perf test' regression test entry affected,
        use perf_missing_features.mmap2 to fallback to not using .mmap2 in older kernels,
        so that new tools can work with kernels where this feature is not present ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5c5e854b
  7. 10 9月, 2013 3 次提交
  8. 06 9月, 2013 7 次提交
  9. 05 9月, 2013 11 次提交
  10. 04 9月, 2013 2 次提交
    • L
      Merge branch 'x86-asmlinkage-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 2a475501
      Linus Torvalds 提交于
      Pull x86/asmlinkage changes from Ingo Molnar:
       "As a preparation for Andi Kleen's LTO patchset (link time
        optimizations using GCC's -flto which build time optimization has
        steadily increased in quality over the past few years and might
        eventually be usable for the kernel too) this tree includes a handful
        of preparatory patches that make function calling convention
        annotations consistent again:
      
         - Mark every function without arguments (or 64bit only) that is used
           by assembly code with asmlinkage()
      
         - Mark every function with parameters or variables that is used by
           assembly code as __visible.
      
        For the vanilla kernel this has documentation, consistency and
        debuggability advantages, for the time being"
      
      * 'x86-asmlinkage-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/asmlinkage: Fix warning in xen asmlinkage change
        x86, asmlinkage, vdso: Mark vdso variables __visible
        x86, asmlinkage, power: Make various symbols used by the suspend asm code visible
        x86, asmlinkage: Make dump_stack visible
        x86, asmlinkage: Make 64bit checksum functions visible
        x86, asmlinkage, paravirt: Add __visible/asmlinkage to xen paravirt ops
        x86, asmlinkage, apm: Make APM data structure used from assembler visible
        x86, asmlinkage: Make syscall tables visible
        x86, asmlinkage: Make several variables used from assembler/linker script visible
        x86, asmlinkage: Make kprobes code visible and fix assembler code
        x86, asmlinkage: Make various syscalls asmlinkage
        x86, asmlinkage: Make 32bit/64bit __switch_to visible
        x86, asmlinkage: Make _*_start_kernel visible
        x86, asmlinkage: Make all interrupt handlers asmlinkage / __visible
        x86, asmlinkage: Change dotraplinkage into __visible on 32bit
        x86: Fix sys_call_table type in asm/syscall.h
      2a475501
    • L
      Merge branch 'x86-asm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 3d7e5fc3
      Linus Torvalds 提交于
      Pull x86/asm changes from Ingo Molnar:
       "Main changes:
      
         - Apply low level mutex optimization on x86-64, by Wedson Almeida
           Filho.
      
         - Change bitops to be naturally 'long', by H Peter Anvin.
      
         - Add TSX-NI opcodes support to the x86 (instrumentation) decoder, by
           Masami Hiramatsu.
      
         - Add clang compatibility adjustments/workarounds, by Jan-Simon
           Möller"
      
      * 'x86-asm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86, doc: Update uaccess.h comment to reflect clang changes
        x86, asm: Fix a compilation issue with clang
        x86, asm: Extend definitions of _ASM_* with a raw format
        x86, insn: Add new opcodes as of June, 2013
        x86/ia32/asm: Remove unused argument in macro
        x86, bitops: Change bitops to be native operand size
        x86: Use asm-goto to implement mutex fast path on x86-64
      3d7e5fc3