1. 29 2月, 2016 11 次提交
  2. 17 2月, 2016 1 次提交
  3. 22 1月, 2016 1 次提交
  4. 06 1月, 2016 2 次提交
  5. 06 10月, 2015 1 次提交
    • T
      perf/x86/intel/uncore: Fix multi-segment problem of perf_event_intel_uncore · 712df65c
      Taku Izumi 提交于
      In multi-segment system, uncore devices may belong to buses whose segment
      number is other than 0:
      
        ....
        0000:ff:10.5 System peripheral: Intel Corporation Xeon E5 v3/Core i7 Scratchpad & Semaphore Registers (rev 03)
        ...
        0001:7f:10.5 System peripheral: Intel Corporation Xeon E5 v3/Core i7 Scratchpad & Semaphore Registers (rev 03)
        ...
        0001:bf:10.5 System peripheral: Intel Corporation Xeon E5 v3/Core i7 Scratchpad & Semaphore Registers (rev 03)
        ...
        0001:ff:10.5 System peripheral: Intel Corporation Xeon E5 v3/Core i7 Scratchpad & Semaphore Registers (rev 03
        ...
      
      In that case, relation of bus number and physical id may be broken
      because "uncore_pcibus_to_physid" doesn't take account of PCI segment.
      For example, bus 0000:ff and 0001:ff uses the same entry of
      "uncore_pcibus_to_physid" array.
      
      This patch fixes this problem by introducing the segment-aware pci2phy_map instead.
      Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: acme@kernel.org
      Cc: hpa@zytor.com
      Link: http://lkml.kernel.org/r/1443096621-4119-1-git-send-email-izumi.taku@jp.fujitsu.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      712df65c
  6. 04 8月, 2015 2 次提交
  7. 09 6月, 2015 1 次提交
    • I
      Revert "perf/x86/intel/uncore: Move uncore_box_init() out of driver initialization" · 15c12479
      Ingo Molnar 提交于
      This reverts commit c05199e5.
      
      Vince Weaver reported the following crash while perf fuzzing:
      
      [   79.473121] kernel BUG at mm/vmalloc.c:1335!
      [   79.694391] Call Trace:
      [   79.696997]  <IRQ>
      [   79.699090]  [<ffffffff811b2130>] get_vm_area_caller+0x40/0x50
      [   79.705505]  [<ffffffff81039f4d>] ? snb_uncore_imc_init_box+0x6d/0x90
      [   79.712414]  [<ffffffff810635e5>] __ioremap_caller+0x195/0x350
      [   79.718610]  [<ffffffff81039f4d>] ? snb_uncore_imc_init_box+0x6d/0x90
      [   79.725462]  [<ffffffff81427f6b>] ? debug_object_activate+0x14b/0x1e0
      [   79.732346]  [<ffffffff810637b7>] ioremap_nocache+0x17/0x20
      [   79.738283]  [<ffffffff81039f4d>] snb_uncore_imc_init_box+0x6d/0x90
      [   79.744945]  [<ffffffff81039cf7>] snb_uncore_imc_event_start+0xb7/0x110
      [   79.752020]  [<ffffffff81039d97>] snb_uncore_imc_event_add+0x47/0x60
      [   79.758832]  [<ffffffff81162cbb>] event_sched_in.isra.85+0xfb/0x330
      [   79.765519]  [<ffffffff81162f5f>] group_sched_in+0x6f/0x1e0
      [   79.771481]  [<ffffffff8101df1a>] ? native_sched_clock+0x2a/0x90
      [   79.777858]  [<ffffffff811637bc>] __perf_event_enable+0x25c/0x2a0
      [   79.784418]  [<ffffffff810f3e69>] ? tick_nohz_irq_exit+0x29/0x30
      [   79.790820]  [<ffffffff8115ef30>] ? cpu_clock_event_start+0x40/0x40
      [   79.797546]  [<ffffffff8115ef80>] remote_function+0x50/0x60
      [   79.803535]  [<ffffffff810f8cd1>] flush_smp_call_function_queue+0x81/0x180
      [   79.810840]  [<ffffffff810f9763>] generic_smp_call_function_single_interrupt+0x13/0x60
      [   79.819328]  [<ffffffff8104b5e8>] smp_trace_call_function_single_interrupt+0x38/0xc0
      [   79.827614]  [<ffffffff816de9be>] trace_call_function_single_interrupt+0x6e/0x80
      [   79.835465]  <EOI>
      [   79.837543]  [<ffffffff8156e8b5>] ? cpuidle_enter_state+0x65/0x160
      [   79.844377]  [<ffffffff8156e8a1>] ? cpuidle_enter_state+0x51/0x160
      [   79.851015]  [<ffffffff8156e9e7>] cpuidle_enter+0x17/0x20
      [   79.856791]  [<ffffffff810b6e39>] cpu_startup_entry+0x399/0x440
      [   79.863165]  [<ffffffff816c9ddb>] rest_init+0xbb/0xd0
      
      The offending commit is clearly confused as it moves heavy initialization
      work into IPI context.
      
      Revert it.
      Reported-by: NVince Weaver <vincent.weaver@maine.edu>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Yan, Zheng <zheng.z.yan@intel.com>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      15c12479
  8. 27 5月, 2015 2 次提交
    • P
      perf/x86: Improve HT workaround GP counter constraint · cc1790cf
      Peter Zijlstra 提交于
      The (SNB/IVB/HSW) HT bug only affects events that can be programmed
      onto GP counters, therefore we should only limit the number of GP
      counters that can be used per cpu -- iow we should not constrain the
      FP counters.
      
      Furthermore, we should only enfore such a limit when there are in fact
      exclusive events being scheduled on either sibling.
      Reported-by: NVince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      [ Fixed build fail for the !CONFIG_CPU_SUP_INTEL case. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      cc1790cf
    • P
      perf/x86: Fix event/group validation · b371b594
      Peter Zijlstra 提交于
      Commit 43b45780 ("perf/x86: Reduce stack usage of
      x86_schedule_events()") violated the rule that 'fake' scheduling; as
      used for event/group validation; should not change the event state.
      
      This went mostly un-noticed because repeated calls of
      x86_pmu::get_event_constraints() would give the same result. And
      x86_pmu::put_event_constraints() would mostly not do anything.
      
      Commit e979121b ("perf/x86/intel: Implement cross-HT corruption
      bug workaround") made the situation much worse by actually setting the
      event->hw.constraint value to NULL, so when validation and actual
      scheduling interact we get NULL ptr derefs.
      
      Fix it by removing the constraint pointer from the event and move it
      back to an array, this time in cpuc instead of on the stack.
      
      validate_group()
        x86_schedule_events()
          event->hw.constraint = c; # store
      
            <context switch>
              perf_task_event_sched_in()
                ...
                  x86_schedule_events();
                    event->hw.constraint = c2; # store
      
                    ...
      
                    put_event_constraints(event); # assume failure to schedule
                      intel_put_event_constraints()
                        event->hw.constraint = NULL;
      
            <context switch end>
      
          c = event->hw.constraint; # read -> NULL
      
          if (!test_bit(hwc->idx, c->idxmsk)) # <- *BOOM* NULL deref
      
      This in particular is possible when the event in question is a
      cpu-wide event and group-leader, where the validate_group() tries to
      add an event to the group.
      Reported-by: NVince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Hunter <ahh@google.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Maria Dimakopoulou <maria.n.dimakopoulou@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 43b45780 ("perf/x86: Reduce stack usage of x86_schedule_events()")
      Fixes: e979121b ("perf/x86/intel: Implement cross-HT corruption bug workaround")
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      b371b594
  9. 11 5月, 2015 1 次提交
  10. 22 4月, 2015 1 次提交
  11. 28 1月, 2015 1 次提交
  12. 11 12月, 2014 1 次提交
    • J
      perf/x86/intel/uncore: Make sure only uncore events are collected · af91568e
      Jiri Olsa 提交于
      The uncore_collect_events functions assumes that event group
      might contain only uncore events which is wrong, because it
      might contain any type of events.
      
      This bug leads to uncore framework touching 'not' uncore events,
      which could end up all sorts of bugs.
      
      One was triggered by Vince's perf fuzzer, when the uncore code
      touched breakpoint event private event space as if it was uncore
      event and caused BUG:
      
         BUG: unable to handle kernel paging request at ffffffff82822068
         IP: [<ffffffff81020338>] uncore_assign_events+0x188/0x250
         ...
      
      The code in uncore_assign_events() function was looking for
      event->hw.idx data while the event was initialized as a
      breakpoint with different members in event->hw union.
      
      This patch forces uncore_collect_events() to collect only uncore
      events.
      Reported-by: NVince Weaver <vince@deater.net>
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Yan, Zheng <zheng.z.yan@intel.com>
      Cc: <stable@vger.kernel.org>
      Link: http://lkml.kernel.org/r/1418243031-20367-2-git-send-email-jolsa@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      af91568e
  13. 08 11月, 2014 1 次提交
  14. 03 10月, 2014 1 次提交
  15. 24 9月, 2014 2 次提交
  16. 09 9月, 2014 1 次提交
  17. 13 8月, 2014 6 次提交
  18. 16 7月, 2014 1 次提交
  19. 05 7月, 2014 1 次提交
  20. 20 3月, 2014 1 次提交
    • S
      x86, intel, uncore: Fix CPU hotplug callback registration · 2c666ada
      Srivatsa S. Bhat 提交于
      Subsystems that want to register CPU hotplug callbacks, as well as perform
      initialization for the CPUs that are already online, often do it as shown
      below:
      
      	get_online_cpus();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	register_cpu_notifier(&foobar_cpu_notifier);
      
      	put_online_cpus();
      
      This is wrong, since it is prone to ABBA deadlocks involving the
      cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
      with CPU hotplug operations).
      
      Instead, the correct and race-free way of performing the callback
      registration is:
      
      	cpu_notifier_register_begin();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	/* Note the use of the double underscored version of the API */
      	__register_cpu_notifier(&foobar_cpu_notifier);
      
      	cpu_notifier_register_done();
      
      Fix the uncore code in intel-x86 by using this latter form of callback
      registration.
      
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2c666ada
  21. 14 3月, 2014 1 次提交