1. 12 7月, 2013 4 次提交
    • P
      perf: Fix perf_lock_task_context() vs RCU · 058ebd0e
      Peter Zijlstra 提交于
      Jiri managed to trigger this warning:
      
       [] ======================================================
       [] [ INFO: possible circular locking dependency detected ]
       [] 3.10.0+ #228 Tainted: G        W
       [] -------------------------------------------------------
       [] p/6613 is trying to acquire lock:
       []  (rcu_node_0){..-...}, at: [<ffffffff810ca797>] rcu_read_unlock_special+0xa7/0x250
       []
       [] but task is already holding lock:
       []  (&ctx->lock){-.-...}, at: [<ffffffff810f2879>] perf_lock_task_context+0xd9/0x2c0
       []
       [] which lock already depends on the new lock.
       []
       [] the existing dependency chain (in reverse order) is:
       []
       [] -> #4 (&ctx->lock){-.-...}:
       [] -> #3 (&rq->lock){-.-.-.}:
       [] -> #2 (&p->pi_lock){-.-.-.}:
       [] -> #1 (&rnp->nocb_gp_wq[1]){......}:
       [] -> #0 (rcu_node_0){..-...}:
      
      Paul was quick to explain that due to preemptible RCU we cannot call
      rcu_read_unlock() while holding scheduler (or nested) locks when part
      of the read side critical section was preemptible.
      
      Therefore solve it by making the entire RCU read side non-preemptible.
      
      Also pull out the retry from under the non-preempt to play nice with RT.
      Reported-by: NJiri Olsa <jolsa@redhat.com>
      Helped-out-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      058ebd0e
    • J
      perf: Remove WARN_ON_ONCE() check in __perf_event_enable() for valid scenario · 06f41796
      Jiri Olsa 提交于
      The '!ctx->is_active' check has a valid scenario, so
      there's no need for the warning.
      
      The reason is that there's a time window between the
      'ctx->is_active' check in the perf_event_enable() function
      and the __perf_event_enable() function having:
      
        - IRQs on
        - ctx->lock unlocked
      
      where the task could be killed and 'ctx' deactivated by
      perf_event_exit_task(), ending up with the warning below.
      
      So remove the WARN_ON_ONCE() check and add comments to
      explain it all.
      
      This addresses the following warning reported by Vince Weaver:
      
      [  324.983534] ------------[ cut here ]------------
      [  324.984420] WARNING: at kernel/events/core.c:1953 __perf_event_enable+0x187/0x190()
      [  324.984420] Modules linked in:
      [  324.984420] CPU: 19 PID: 2715 Comm: nmi_bug_snb Not tainted 3.10.0+ #246
      [  324.984420] Hardware name: Supermicro X8DTN/X8DTN, BIOS 4.6.3 01/08/2010
      [  324.984420]  0000000000000009 ffff88043fce3ec8 ffffffff8160ea0b ffff88043fce3f00
      [  324.984420]  ffffffff81080ff0 ffff8802314fdc00 ffff880231a8f800 ffff88043fcf7860
      [  324.984420]  0000000000000286 ffff880231a8f800 ffff88043fce3f10 ffffffff8108103a
      [  324.984420] Call Trace:
      [  324.984420]  <IRQ>  [<ffffffff8160ea0b>] dump_stack+0x19/0x1b
      [  324.984420]  [<ffffffff81080ff0>] warn_slowpath_common+0x70/0xa0
      [  324.984420]  [<ffffffff8108103a>] warn_slowpath_null+0x1a/0x20
      [  324.984420]  [<ffffffff81134437>] __perf_event_enable+0x187/0x190
      [  324.984420]  [<ffffffff81130030>] remote_function+0x40/0x50
      [  324.984420]  [<ffffffff810e51de>] generic_smp_call_function_single_interrupt+0xbe/0x130
      [  324.984420]  [<ffffffff81066a47>] smp_call_function_single_interrupt+0x27/0x40
      [  324.984420]  [<ffffffff8161fd2f>] call_function_single_interrupt+0x6f/0x80
      [  324.984420]  <EOI>  [<ffffffff816161a1>] ? _raw_spin_unlock_irqrestore+0x41/0x70
      [  324.984420]  [<ffffffff8113799d>] perf_event_exit_task+0x14d/0x210
      [  324.984420]  [<ffffffff810acd04>] ? switch_task_namespaces+0x24/0x60
      [  324.984420]  [<ffffffff81086946>] do_exit+0x2b6/0xa40
      [  324.984420]  [<ffffffff8161615c>] ? _raw_spin_unlock_irq+0x2c/0x30
      [  324.984420]  [<ffffffff81087279>] do_group_exit+0x49/0xc0
      [  324.984420]  [<ffffffff81096854>] get_signal_to_deliver+0x254/0x620
      [  324.984420]  [<ffffffff81043057>] do_signal+0x57/0x5a0
      [  324.984420]  [<ffffffff8161a164>] ? __do_page_fault+0x2a4/0x4e0
      [  324.984420]  [<ffffffff8161665c>] ? retint_restore_args+0xe/0xe
      [  324.984420]  [<ffffffff816166cd>] ? retint_signal+0x11/0x84
      [  324.984420]  [<ffffffff81043605>] do_notify_resume+0x65/0x80
      [  324.984420]  [<ffffffff81616702>] retint_signal+0x46/0x84
      [  324.984420] ---[ end trace 442ec2f04db3771a ]---
      Reported-by: NVince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Suggested-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1373384651-6109-2-git-send-email-jolsa@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      06f41796
    • J
      perf: Clone child context from parent context pmu · 734df5ab
      Jiri Olsa 提交于
      Currently when the child context for inherited events is
      created, it's based on the pmu object of the first event
      of the parent context.
      
      This is wrong for the following scenario:
      
        - HW context having HW and SW event
        - HW event got removed (closed)
        - SW event stays in HW context as the only event
          and its pmu is used to clone the child context
      
      The issue starts when the cpu context object is touched
      based on the pmu context object (__get_cpu_context). In
      this case the HW context will work with SW cpu context
      ending up with following WARN below.
      
      Fixing this by using parent context pmu object to clone
      from child context.
      
      Addresses the following warning reported by Vince Weaver:
      
      [ 2716.472065] ------------[ cut here ]------------
      [ 2716.476035] WARNING: at kernel/events/core.c:2122 task_ctx_sched_out+0x3c/0x)
      [ 2716.476035] Modules linked in: nfsd auth_rpcgss oid_registry nfs_acl nfs locn
      [ 2716.476035] CPU: 0 PID: 3164 Comm: perf_fuzzer Not tainted 3.10.0-rc4 #2
      [ 2716.476035] Hardware name: AOpen   DE7000/nMCP7ALPx-DE R1.06 Oct.19.2012, BI2
      [ 2716.476035]  0000000000000000 ffffffff8102e215 0000000000000000 ffff88011fc18
      [ 2716.476035]  ffff8801175557f0 0000000000000000 ffff880119fda88c ffffffff810ad
      [ 2716.476035]  ffff880119fda880 ffffffff810af02a 0000000000000009 ffff880117550
      [ 2716.476035] Call Trace:
      [ 2716.476035]  [<ffffffff8102e215>] ? warn_slowpath_common+0x5b/0x70
      [ 2716.476035]  [<ffffffff810ab2bd>] ? task_ctx_sched_out+0x3c/0x5f
      [ 2716.476035]  [<ffffffff810af02a>] ? perf_event_exit_task+0xbf/0x194
      [ 2716.476035]  [<ffffffff81032a37>] ? do_exit+0x3e7/0x90c
      [ 2716.476035]  [<ffffffff810cd5ab>] ? __do_fault+0x359/0x394
      [ 2716.476035]  [<ffffffff81032fe6>] ? do_group_exit+0x66/0x98
      [ 2716.476035]  [<ffffffff8103dbcd>] ? get_signal_to_deliver+0x479/0x4ad
      [ 2716.476035]  [<ffffffff810ac05c>] ? __perf_event_task_sched_out+0x230/0x2d1
      [ 2716.476035]  [<ffffffff8100205d>] ? do_signal+0x3c/0x432
      [ 2716.476035]  [<ffffffff810abbf9>] ? ctx_sched_in+0x43/0x141
      [ 2716.476035]  [<ffffffff810ac2ca>] ? perf_event_context_sched_in+0x7a/0x90
      [ 2716.476035]  [<ffffffff810ac311>] ? __perf_event_task_sched_in+0x31/0x118
      [ 2716.476035]  [<ffffffff81050dd9>] ? mmdrop+0xd/0x1c
      [ 2716.476035]  [<ffffffff81051a39>] ? finish_task_switch+0x7d/0xa6
      [ 2716.476035]  [<ffffffff81002473>] ? do_notify_resume+0x20/0x5d
      [ 2716.476035]  [<ffffffff813654f5>] ? retint_signal+0x3d/0x78
      [ 2716.476035] ---[ end trace 827178d8a5966c3d ]---
      Reported-by: NVince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1373384651-6109-1-git-send-email-jolsa@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      734df5ab
    • I
      Merge tag 'perf-urgent-for-mingo' of... · c3a1b0cb
      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:
      
       * Fix some freeing bugs on the parsing error paths, from Adrian Hunter.
      
       * Update symbol_conf.nr_events when processing attribute events, fix from Adrian Hunter.
      
       * Fix missing increment in sample parsing when PERF_SAMPLE_STACK_USER
         is present, from Adrian Hunt.
      
       * Fix count parameter to read call in event_format__new, from David Ahern.
      
       * Remove -A/--append option, not working for a long time, from Jiri Olsa.
      
       * Remove -f/--force option, was a no-op for quite some time, from Jiri Olsa.
      
       * Fix -x/--exclude-other option for report command, from Jiri Olsa.
      
       * Cross build fixes, at least one for Android, from Joonsoo Kim.
      
       * Fix memory allocation fail check in mem{set,cpy} 'perf bench' workloads,
         from Kirill A. Shutemov.
      
       * Revert regression in configuration of Python support, from Michael Witten.
      
       * Fix -ldw/-lelf link test when static linking, from Mike Frysinger.
      
       * Fix issues with multiple children processing in perf_evlist__start_workload(),
         from Namhyung Kim.
      
       * Fix broken include in Context.xs ('perf script'), from Ramkumar Ramachandra.
      
       * Fixes for build problems, from Robert Richter.
      
       * Fix a typo of a Power7 event name, from Runzhen Wang.
      
       * Avoid sending SIGTERM to random processes in 'perf stat', fix from Stephane Eranian.
      
       * Fix per-socket output bug for uncore events in 'perf stat', from Stephane Eranian.
      
       * Fix vdso list searching, from Waiman Long.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      c3a1b0cb
  2. 11 7月, 2013 2 次提交
    • R
      perf script: Fix broken include in Context.xs · 750ade7e
      Ramkumar Ramachandra 提交于
      765532c8 (perf script: Finish the rename from trace to script,
      2010-12-23) made a mistake during find-and-replace replacing
      "../../../util/trace-event.h" with "../../../util/script-event.h", a
      non-existent file.  Fix this include.
      Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/r/1373364033-7918-3-git-send-email-artagnon@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      750ade7e
    • M
      perf tools: Fix -ldw/-lelf link test when static linking · d14c4965
      Mike Frysinger 提交于
      Since libelf sometimes uses libpthread, we have to list that after -lelf
      when someone tries to build statically.  Else things go boom:
      
      Makefile:479: *** No libelf.h/libelf found, please install \
      	libelf-dev/elfutils-libelf-devel.  Stop.
      
      Similarly, the -ldw test fails as it often uses -lz:
      
      Makefile:462: No libdw.h found or old libdw.h found or elfutils is older \
      	than 0.138, disables dwarf support. Please install new elfutils-devel/libdw-dev
      
      And if we add debugging to try-cc, we see:
      + echo '#include <dwarf.h>
      
      int main(void)
      {
              Dwarf *dbg = dwarf_begin(0, DWARF_C_READ);
              return (long)dbg;
      }'
      + i686-pc-linux-gnu-gcc -x c - -O2 -pipe -march=atom -mtune=atom -mfpmath=sse -g \
      	-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE \
      	-ldw -lelf -static -lpthread -lrt -lelf -lm -o .24368
      /usr/lib/libdw.a(dwarf_begin_elf.o):function check_section.isra.1: error: undefined reference to 'inflateInit_'
      /usr/lib/libdw.a(dwarf_begin_elf.o):function check_section.isra.1: error: undefined reference to 'inflate'
      /usr/lib/libdw.a(dwarf_begin_elf.o):function check_section.isra.1: error: undefined reference to 'inflateReset'
      /usr/lib/libdw.a(dwarf_begin_elf.o):function check_section.isra.1: error: undefined reference to 'inflateEnd'
      
      + echo '#include <libelf.h>
      
      int main(void)
      {
              Elf *elf = elf_begin(0, ELF_C_READ, 0);
              return (long)elf;
      }'
      + i686-pc-linux-gnu-gcc -x c - -O2 -pipe -march=atom -mtune=atom -mfpmath=sse -g \
      	-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE \
      	-static -lpthread -lrt -lelf -lm -o .19216
      /usr/lib/libelf.a(elf_begin.o):function file_read_elf: error: undefined reference to 'pthread_rwlock_init'
      /usr/lib/libelf.a(elf_begin.o):function __libelf_read_mmaped_file: error: undefined reference to 'pthread_rwlock_init'
      /usr/lib/libelf.a(elf_begin.o):function __libelf_read_mmaped_file: error: undefined reference to 'pthread_rwlock_init'
      /usr/lib/libelf.a(elf_begin.o):function read_file: error: undefined reference to 'pthread_rwlock_init'
      /usr/lib/libelf.a(elf_begin.o):function lock_dup_elf.8072: error: undefined reference to 'pthread_rwlock_unlock'
      /usr/lib/libelf.a(elf_begin.o):function lock_dup_elf.8072: error: undefined reference to 'pthread_rwlock_wrlock'
      /usr/lib/libelf.a(elf_begin.o):function elf_begin: error: undefined reference to 'pthread_rwlock_rdlock'
      /usr/lib/libelf.a(elf_begin.o):function elf_begin: error: undefined reference to 'pthread_rwlock_unlock'
      Signed-off-by: NMike Frysinger <vapier@gentoo.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1368073064-18276-1-git-send-email-vapier@gentoo.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d14c4965
  3. 10 7月, 2013 1 次提交
    • M
      perf tools: Revert regression in configuration of Python support · a363a9da
      Michael Witten 提交于
      Among other things, the following:
      
        commit 31160d7f
        Date:   Tue Jan 8 16:22:36 2013 -0500
        perf tools: Fix GNU make v3.80 compatibility issue
      
      attempts to aid the user by tapping into an existing error message,
      as described in the commit message:
      
        ... Also fix an issue where _get_attempt was called with only
        one argument. This prevented the error message from printing
        the name of the variable that can be used to fix the problem.
      
      or more precisely:
      
        -$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2)))
        +$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2),$(1)))
      
      However, The "missing" argument was in fact missing on purpose; it's
      absence is a signal that the error message should be skipped, because
      the failure would be due to the default value, not any user-supplied
      value.  This can be seen in how `_ge_attempt' uses `gea_err' (in the
      config/utilities.mak file):
      
        _ge_attempt = $(if $(get-executable),$(get-executable),$(_gea_warn)$(call _gea_err,$(2)))
        _gea_warn = $(warning The path '$(1)' is not executable.)
        _gea_err  = $(if $(1),$(error Please set '$(1)' appropriately))
      
      That is, because the argument is no longer missing, the value `$(1)'
      (associated with `_gea_err') always evaluates to true, thus always
      triggering the error condition that is meant to be reserved for
      only the case when a user explicitly supplies an invalid value.
      
      Concretely, the result is a regression in the Makefile's configuration
      of python support; rather than gracefully disable support when the
      relevant executables cannot be found according to default values, the
      build process halts in error as though the user explicitly supplied
      the values.
      
      This new commit simply reverts the offending one-line change.
      Reported-by: NPekka Enberg <penberg@kernel.org>
      Link: http://lkml.kernel.org/r/CAOJsxLHv17Ys3M7P5q25imkUxQW6LE_vABxh1N3Tt7Mv6Ho4iw@mail.gmail.comSigned-off-by: NMichael Witten <mfwitten@gmail.com>
      a363a9da
  4. 09 7月, 2013 20 次提交
  5. 05 7月, 2013 2 次提交
  6. 03 7月, 2013 11 次提交