1. 05 12月, 2011 1 次提交
  2. 14 11月, 2011 3 次提交
  3. 01 11月, 2011 3 次提交
  4. 19 10月, 2011 2 次提交
  5. 14 10月, 2011 2 次提交
  6. 10 10月, 2011 4 次提交
  7. 06 10月, 2011 1 次提交
  8. 28 9月, 2011 1 次提交
  9. 26 9月, 2011 1 次提交
  10. 14 9月, 2011 1 次提交
    • H
      x86, mce: Do not call del_timer_sync() in IRQ context · 9aaef96f
      Hidetoshi Seto 提交于
      del_timer_sync() can cause a deadlock when called in interrupt context.
      It is used with on_each_cpu() in some parts for sysfs files like bank*,
      check_interval, cmci_disabled and ignore_ce.
      
      However, use of on_each_cpu() results in calling the function passed
      as the argument in interrupt context. This causes a flood of nested
      warnings from del_timer_sync() (it runs on each CPU) caused even by a
      simple file access like:
      
      $ echo 300 > /sys/devices/system/machinecheck/machinecheck0/check_interval
      
      Fortunately, these MCE-specific files are rarely used and AFAIK only few
      MCE geeks experience this warning.
      
      To remove the warning, move timer deletion outside of the interrupt
      context.
      Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      9aaef96f
  11. 13 9月, 2011 5 次提交
  12. 08 9月, 2011 1 次提交
  13. 31 8月, 2011 1 次提交
    • A
      x86, perf: Check that current->mm is alive before getting user callchain · 20afc60f
      Andrey Vagin 提交于
      An event may occur when an mm is already released.
      
      I added an event in dequeue_entity() and caught a panic with
      the following backtrace:
      
      [  434.421110] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
      [  434.421258] IP: [<ffffffff810464ac>] __get_user_pages_fast+0x9c/0x120
      ...
      [  434.421258] Call Trace:
      [  434.421258]  [<ffffffff8101ae81>] copy_from_user_nmi+0x51/0xf0
      [  434.421258]  [<ffffffff8109a0d5>] ? sched_clock_local+0x25/0x90
      [  434.421258]  [<ffffffff8101b048>] perf_callchain_user+0x128/0x170
      [  434.421258]  [<ffffffff811154cd>] ? __perf_event_header__init_id+0xed/0x100
      [  434.421258]  [<ffffffff81116690>] perf_prepare_sample+0x200/0x280
      [  434.421258]  [<ffffffff81118da8>] __perf_event_overflow+0x1b8/0x290
      [  434.421258]  [<ffffffff81065240>] ? tg_shares_up+0x0/0x670
      [  434.421258]  [<ffffffff8104fe1a>] ? walk_tg_tree+0x6a/0xb0
      [  434.421258]  [<ffffffff81118f44>] perf_swevent_overflow+0xc4/0xf0
      [  434.421258]  [<ffffffff81119150>] do_perf_sw_event+0x1e0/0x250
      [  434.421258]  [<ffffffff81119204>] perf_tp_event+0x44/0x70
      [  434.421258]  [<ffffffff8105701f>] ftrace_profile_sched_block+0xdf/0x110
      [  434.421258]  [<ffffffff8106121d>] dequeue_entity+0x2ad/0x2d0
      [  434.421258]  [<ffffffff810614ec>] dequeue_task_fair+0x1c/0x60
      [  434.421258]  [<ffffffff8105818a>] dequeue_task+0x9a/0xb0
      [  434.421258]  [<ffffffff810581e2>] deactivate_task+0x42/0xe0
      [  434.421258]  [<ffffffff814bc019>] thread_return+0x191/0x808
      [  434.421258]  [<ffffffff81098a44>] ? switch_task_namespaces+0x24/0x60
      [  434.421258]  [<ffffffff8106f4c4>] do_exit+0x464/0x910
      [  434.421258]  [<ffffffff8106f9c8>] do_group_exit+0x58/0xd0
      [  434.421258]  [<ffffffff8106fa57>] sys_exit_group+0x17/0x20
      [  434.421258]  [<ffffffff8100b202>] system_call_fastpath+0x16/0x1b
      Signed-off-by: NAndrey Vagin <avagin@openvz.org>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: stable@kernel.org
      Link: http://lkml.kernel.org/r/1314693156-24131-1-git-send-email-avagin@openvz.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>
      20afc60f
  14. 26 8月, 2011 1 次提交
  15. 14 8月, 2011 1 次提交
  16. 10 8月, 2011 1 次提交
    • S
      x86, amd: Include elf.h explicitly, prepare the code for the module.h split · 5cdd174f
      Stephen Rothwell 提交于
      When the moduleu.h splitting tree is merged to the latest
      tip:x86/cpu tree, the x86_64 allmodconfig build fails like this:
      
       arch/x86/kernel/cpu/amd.c: In function 'bsp_init_amd':
       arch/x86/kernel/cpu/amd.c:437:3: error: 'va_align' undeclared (first use in this function)
       arch/x86/kernel/cpu/amd.c:438:23: error: 'ALIGN_VA_32' undeclared (first use in this function)
       arch/x86/kernel/cpu/amd.c:438:37: error: 'ALIGN_VA_64' undeclared (first use in this function)
      
      This is caused by the module.h split up intreacting with commit
      dfb09f9b ("x86, amd: Avoid cache aliasing penalties on AMD
      family 15h") from the tip:x86/cpu tree.
      
      I have added the following patch for today (this, or something
      similar, could be applied to the tip tree directly - the
      export.h include below was added by the module.h splitup).
      
      So include elf.h to use va_align and remove this implicit
      dependency on module.h doing it for us.
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Link: http://lkml.kernel.org/r/20110810114956.238d66772883636e3040d29f@canb.auug.org.auSigned-off-by: NIngo Molnar <mingo@elte.hu>
      5cdd174f
  17. 09 8月, 2011 1 次提交
  18. 06 8月, 2011 3 次提交
  19. 01 8月, 2011 1 次提交
    • H
      x86, random: Verify RDRAND functionality and allow it to be disabled · 49d859d7
      H. Peter Anvin 提交于
      If the CPU declares that RDRAND is available, go through a guranteed
      reseed sequence, and make sure that it is actually working (producing
      data.)   If it does not, disable the CPU feature flag.
      
      Allow RDRAND to be disabled on the command line (as opposed to at
      compile time) for a user who has special requirements with regards to
      random numbers.
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      49d859d7
  20. 27 7月, 2011 1 次提交
  21. 22 7月, 2011 2 次提交
  22. 16 7月, 2011 1 次提交
  23. 15 7月, 2011 2 次提交
    • C
      perf, x86: P4 PMU - Introduce event alias feature · f9129870
      Cyrill Gorcunov 提交于
      Instead of hw_nmi_watchdog_set_attr() weak function
      and appropriate x86_pmu::hw_watchdog_set_attr() call
      we introduce even alias mechanism which allow us
      to drop this routines completely and isolate quirks
      of Netburst architecture inside P4 PMU code only.
      
      The main idea remains the same though -- to allow
      nmi-watchdog and perf top run simultaneously.
      
      Note the aliasing mechanism applies to generic
      PERF_COUNT_HW_CPU_CYCLES event only because arbitrary
      event (say passed as RAW initially) might have some
      additional bits set inside ESCR register changing
      the behaviour of event and we can't guarantee anymore
      that alias event will give the same result.
      
      P.S. Thanks a huge to Don and Steven for for testing
           and early review.
      Acked-by: NDon Zickus <dzickus@redhat.com>
      Tested-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
      CC: Ingo Molnar <mingo@elte.hu>
      CC: Peter Zijlstra <a.p.zijlstra@chello.nl>
      CC: Stephane Eranian <eranian@google.com>
      CC: Lin Ming <ming.m.lin@intel.com>
      CC: Arnaldo Carvalho de Melo <acme@redhat.com>
      CC: Frederic Weisbecker <fweisbec@gmail.com>
      Link: http://lkml.kernel.org/r/20110708201712.GS23657@sunSigned-off-by: NSteven Rostedt <rostedt@goodmis.org>
      f9129870
    • L
      x86, intel, power: Initialize MSR_IA32_ENERGY_PERF_BIAS · abe48b10
      Len Brown 提交于
      Since 2.6.36 (23016bf0), Linux prints the existence of "epb" in /proc/cpuinfo,
      Since 2.6.38 (d5532ee7), the x86_energy_perf_policy(8) utility has
      been available in-tree to update MSR_IA32_ENERGY_PERF_BIAS.
      
      However, the typical BIOS fails to initialize the MSR, presumably
      because this is handled by high-volume shrink-wrap operating systems...
      
      Linux distros, on the other hand, do not yet invoke x86_energy_perf_policy(8).
      As a result, WSM-EP, SNB, and later hardware from Intel will run in its
      default hardware power-on state (performance), which assumes that users
      care for performance at all costs and not for energy efficiency.
      While that is fine for performance benchmarks, the hardware's intended default
      operating point is "normal" mode...
      
      Initialize the MSR to the "normal" by default during kernel boot.
      
      x86_energy_perf_policy(8) is available to change the default after boot,
      should the user have a different preference.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1107140051020.18606@x980Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: <stable@kernel.org>
      abe48b10