1. 03 9月, 2010 1 次提交
    • D
      perf, x86: Fix accidentally ack'ing a second event on intel perf counter · 2e556b5b
      Don Zickus 提交于
      During testing of a patch to stop having the perf subsytem
      swallow nmis, it was uncovered that Nehalem boxes were randomly
      getting unknown nmis when using the perf tool.
      
      Moving the ack'ing of the PMI closer to when we get the status
      allows the hardware to properly re-set the PMU bit signaling
      another PMI was triggered during the processing of the first
      PMI.  This allows the new logic for dealing with the
      shortcomings of multiple PMIs to handle the extra NMI by
      'eat'ing it later.
      
      Now one can wonder why are we getting a second PMI when we
      disable all the PMUs in the begining of the NMI handler to
      prevent such a case, for that I do not know.  But I know the fix
      below helps deal with this quirk.
      
      Tested on multiple Nehalems where the problem was occuring.
      With the patch, the code now loops a second time to handle the
      second PMI (whereas before it was not).
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Cc: peterz@infradead.org
      Cc: robert.richter@amd.com
      Cc: gorcunov@gmail.com
      Cc: fweisbec@gmail.com
      Cc: ying.huang@intel.com
      Cc: ming.m.lin@intel.com
      Cc: eranian@google.com
      LKML-Reference: <1283454469-1909-2-git-send-email-dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2e556b5b
  2. 02 9月, 2010 1 次提交
    • R
      oprofile, x86: fix init_sysfs() function stub · 269f45c2
      Robert Richter 提交于
      The use of the return value of init_sysfs() with commit
      
       10f0412f oprofile, x86: fix init_sysfs error handling
      
      discovered the following build error for !CONFIG_PM:
      
       .../linux/arch/x86/oprofile/nmi_int.c: In function ‘op_nmi_init’:
       .../linux/arch/x86/oprofile/nmi_int.c:784: error: expected expression before ‘do’
       make[2]: *** [arch/x86/oprofile/nmi_int.o] Error 1
       make[1]: *** [arch/x86/oprofile] Error 2
      
      This patch fixes this.
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Cc: stable@kernel.org
      Signed-off-by: NRobert Richter <robert.richter@amd.com>
      269f45c2
  3. 31 8月, 2010 1 次提交
  4. 25 8月, 2010 1 次提交
  5. 23 8月, 2010 2 次提交
  6. 22 8月, 2010 1 次提交
  7. 20 8月, 2010 2 次提交
    • D
      x86, apic: Fix apic=debug boot crash · 05e40760
      Daniel Kiper 提交于
      Fix a boot crash when apic=debug is used and the APIC is
      not properly initialized.
      
      This issue appears during Xen Dom0 kernel boot but the
      fix is generic and the crash could occur on real hardware
      as well.
      Signed-off-by: NDaniel Kiper <dkiper@net-space.pl>
      Cc: xen-devel@lists.xensource.com
      Cc: konrad.wilk@oracle.com
      Cc: jeremy@goop.org
      Cc: <stable@kernel.org> # .35.x, .34.x, .33.x, .32.x
      LKML-Reference: <20100819224616.GB9967@router-fw-old.local.net-space.pl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      05e40760
    • B
      x86, hotplug: Serialize CPU hotplug to avoid bringup concurrency issues · d7c53c9e
      Borislav Petkov 提交于
      When testing cpu hotplug code on 32-bit we kept hitting the "CPU%d:
      Stuck ??" message due to multiple cores concurrently accessing the
      cpu_callin_mask, among others.
      
      Since these codepaths are not protected from concurrent access due to
      the fact that there's no sane reason for making an already complex
      code unnecessarily more complex - we hit the issue only when insanely
      switching cores off- and online - serialize hotplugging cores on the
      sysfs level and be done with it.
      
      [ v2.1: fix !HOTPLUG_CPU build ]
      
      Cc: <stable@kernel.org>
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      LKML-Reference: <20100819181029.GC17171@aftab>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      d7c53c9e
  8. 19 8月, 2010 4 次提交
    • K
      kprobes/x86: Fix the return address of multiple kretprobes · 737480a0
      KUMANO Syuhei 提交于
      Fix the return address of subsequent kretprobes when multiple
      kretprobes are set on the same function.
      
      For example:
      
       # cd /sys/kernel/debug/tracing
       # echo "r:event1 sys_symlink" > kprobe_events
       # echo "r:event2 sys_symlink" >> kprobe_events
       # echo 1 > events/kprobes/enable
       # ln -s /tmp/foo /tmp/bar
      
      (without this patch)
      
       # cat trace
                    ln-897   [000] 20404.133727: event1: (kretprobe_trampoline+0x0/0x4c <- sys_symlink)
                    ln-897   [000] 20404.133747: event2: (system_call_fastpath+0x16/0x1b <- sys_symlink)
      
      (with this patch)
      
       # cat trace
                    ln-740   [000] 13799.491076: event1: (system_call_fastpath+0x16/0x1b <- sys_symlink)
                    ln-740   [000] 13799.491096: event2: (system_call_fastpath+0x16/0x1b <- sys_symlink)
      Signed-off-by: NKUMANO Syuhei <kumano.prog@gmail.com>
      Reviewed-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      LKML-Reference: <1281853084.3254.11.camel@camp10-laptop>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      737480a0
    • H
      x86-32: Fix dummy trampoline-related inline stubs · 8848a910
      H. Peter Anvin 提交于
      Fix dummy inline stubs for trampoline-related functions when no
      trampolines exist (until we get rid of the no-trampoline case
      entirely.)
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Joerg Roedel <joerg.roedel@amd.com>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      LKML-Reference: <4C6C294D.3030404@zytor.com>
      8848a910
    • J
      x86-32: Separate 1:1 pagetables from swapper_pg_dir · fd89a137
      Joerg Roedel 提交于
      This patch fixes machine crashes which occur when heavily exercising the
      CPU hotplug codepaths on a 32-bit kernel. These crashes are caused by
      AMD Erratum 383 and result in a fatal machine check exception. Here's
      the scenario:
      
      1. On 32-bit, the swapper_pg_dir page table is used as the initial page
      table for booting a secondary CPU.
      
      2. To make this work, swapper_pg_dir needs a direct mapping of physical
      memory in it (the low mappings). By adding those low, large page (2M)
      mappings (PAE kernel), we create the necessary conditions for Erratum
      383 to occur.
      
      3. Other CPUs which do not participate in the off- and onlining game may
      use swapper_pg_dir while the low mappings are present (when leave_mm is
      called). For all steps below, the CPU referred to is a CPU that is using
      swapper_pg_dir, and not the CPU which is being onlined.
      
      4. The presence of the low mappings in swapper_pg_dir can result
      in TLB entries for addresses below __PAGE_OFFSET to be established
      speculatively. These TLB entries are marked global and large.
      
      5. When the CPU with such TLB entry switches to another page table, this
      TLB entry remains because it is global.
      
      6. The process then generates an access to an address covered by the
      above TLB entry but there is a permission mismatch - the TLB entry
      covers a large global page not accessible to userspace.
      
      7. Due to this permission mismatch a new 4kb, user TLB entry gets
      established. Further, Erratum 383 provides for a small window of time
      where both TLB entries are present. This results in an uncorrectable
      machine check exception signalling a TLB multimatch which panics the
      machine.
      
      There are two ways to fix this issue:
      
              1. Always do a global TLB flush when a new cr3 is loaded and the
              old page table was swapper_pg_dir. I consider this a hack hard
              to understand and with performance implications
      
              2. Do not use swapper_pg_dir to boot secondary CPUs like 64-bit
              does.
      
      This patch implements solution 2. It introduces a trampoline_pg_dir
      which has the same layout as swapper_pg_dir with low_mappings. This page
      table is used as the initial page table of the booting CPU. Later in the
      bringup process, it switches to swapper_pg_dir and does a global TLB
      flush. This fixes the crashes in our test cases.
      
      -v2: switch to swapper_pg_dir right after entering start_secondary() so
      that we are able to access percpu data which might not be mapped in the
      trampoline page table.
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      LKML-Reference: <20100816123833.GB28147@aftab>
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      fd89a137
    • H
      x86, cpu: Fix regression in AMD errata checking code · 07a7795c
      Hans Rosenfeld 提交于
      A bug in the family-model-stepping matching code caused the presence of
      errata to go undetected when OSVW was not used. This causes hangs on
      some K8 systems because the E400 workaround is not enabled.
      Signed-off-by: NHans Rosenfeld <hans.rosenfeld@amd.com>
      LKML-Reference: <1282141190-930137-1-git-send-email-hans.rosenfeld@amd.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      07a7795c
  9. 18 8月, 2010 2 次提交
    • Z
      perf, x86: Fix Intel-nhm PMU programming errata workaround · 351af072
      Zhang, Yanmin 提交于
      Fix the Errata AAK100/AAP53/BD53 workaround, the officialy documented
      workaround we implemented in:
      
       11164cd4: perf, x86: Add Nehelem PMU programming errata workaround
      
      doesn't actually work fully and causes a stuck PMU state
      under load and non-functioning perf profiling.
      
      A functional workaround was found by trial & error.
      
      Affects all Nehalem-class Intel PMUs.
      Signed-off-by: NZhang Yanmin <yanmin_zhang@linux.intel.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1281073148.2125.63.camel@ymzhang.sh.intel.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: <stable@kernel.org> # .35.x
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      351af072
    • D
      Make do_execve() take a const filename pointer · d7627467
      David Howells 提交于
      Make do_execve() take a const filename pointer so that kernel_execve() compiles
      correctly on ARM:
      
      arch/arm/kernel/sys_arm.c:88: warning: passing argument 1 of 'do_execve' discards qualifiers from pointer target type
      
      This also requires the argv and envp arguments to be consted twice, once for
      the pointer array and once for the strings the array points to.  This is
      because do_execve() passes a pointer to the filename (now const) to
      copy_strings_kernel().  A simpler alternative would be to cast the filename
      pointer in do_execve() when it's passed to copy_strings_kernel().
      
      do_execve() may not change any of the strings it is passed as part of the argv
      or envp lists as they are some of them in .rodata, so marking these strings as
      const should be fine.
      
      Further kernel_execve() and sys_execve() need to be changed to match.
      
      This has been test built on x86_64, frv, arm and mips.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Tested-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d7627467
  10. 17 8月, 2010 2 次提交
  11. 15 8月, 2010 4 次提交
    • X
      KVM: destroy workqueue on kvm_create_pit() failures · 3185bf8c
      Xiaotian Feng 提交于
      kernel needs to destroy workqueue if kvm_create_pit() fails, otherwise
      after pit is freed, the workqueue is leaked.
      Signed-off-by: NXiaotian Feng <dfeng@redhat.com>
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Cc: Gregory Haskins <ghaskins@novell.com>
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      3185bf8c
    • X
      KVM: fix poison overwritten caused by using wrong xstate size · f45755b8
      Xiaotian Feng 提交于
      fpu.state is allocated from task_xstate_cachep, the size of task_xstate_cachep
      is xstate_size. xstate_size is set from cpuid instruction, which is often
      smaller than sizeof(struct xsave_struct). kvm is using sizeof(struct xsave_struct)
      to fill in/out fpu.state.xsave, as what we allocated for fpu.state is
      xstate_size, kernel will write out of memory and caused poison/redzone/padding
      overwritten warnings.
      Signed-off-by: NXiaotian Feng <dfeng@redhat.com>
      Reviewed-by: NSheng Yang <sheng@linux.intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Sheng Yang <sheng@linux.intel.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Cc: Jan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      f45755b8
    • S
      defconfig reduction · 8b1bb907
      Sam Ravnborg 提交于
      Use the defconfig files generated by "make savedefconfig" for
      remaining defconfig files.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      8b1bb907
    • S
      archs: replace unifdef-y with header-y · bf56fba6
      Sam Ravnborg 提交于
      unifdef-y and header-y have same semantic, so drop unifdef-y
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      bf56fba6
  12. 14 8月, 2010 2 次提交
  13. 13 8月, 2010 4 次提交
  14. 12 8月, 2010 2 次提交
  15. 11 8月, 2010 4 次提交
  16. 10 8月, 2010 3 次提交
    • S
      x86, ia64, smp: use workqueues unconditionally during do_boot_cpu() · d7a7c573
      Suresh Siddha 提交于
      Workqueues are now initialized as part of the early_initcall().  So they
      are available for use during cold boot process aswell.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d7a7c573
    • A
      gcc-4.6: mm: fix unused but set warnings · 4e60c86b
      Andi Kleen 提交于
      No real bugs, just some dead code and some fixups.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4e60c86b
    • C
      kmap_atomic: make kunmap_atomic() harder to misuse · 597781f3
      Cesar Eduardo Barros 提交于
      kunmap_atomic() is currently at level -4 on Rusty's "Hard To Misuse"
      list[1] ("Follow common convention and you'll get it wrong"), except in
      some architectures when CONFIG_DEBUG_HIGHMEM is set[2][3].
      
      kunmap() takes a pointer to a struct page; kunmap_atomic(), however, takes
      takes a pointer to within the page itself.  This seems to once in a while
      trip people up (the convention they are following is the one from
      kunmap()).
      
      Make it much harder to misuse, by moving it to level 9 on Rusty's list[4]
      ("The compiler/linker won't let you get it wrong").  This is done by
      refusing to build if the type of its first argument is a pointer to a
      struct page.
      
      The real kunmap_atomic() is renamed to kunmap_atomic_notypecheck()
      (which is what you would call in case for some strange reason calling it
      with a pointer to a struct page is not incorrect in your code).
      
      The previous version of this patch was compile tested on x86-64.
      
      [1] http://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html
      [2] In these cases, it is at level 5, "Do it right or it will always
          break at runtime."
      [3] At least mips and powerpc look very similar, and sparc also seems to
          share a common ancestor with both; there seems to be quite some
          degree of copy-and-paste coding here. The include/asm/highmem.h file
          for these three archs mention x86 CPUs at its top.
      [4] http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html
      [5] As an aside, could someone tell me why mn10300 uses unsigned long as
          the first parameter of kunmap_atomic() instead of void *?
      Signed-off-by: NCesar Eduardo Barros <cesarb@cesarb.net>
      Cc: Russell King <linux@arm.linux.org.uk> (arch/arm)
      Cc: Ralf Baechle <ralf@linux-mips.org> (arch/mips)
      Cc: David Howells <dhowells@redhat.com> (arch/frv, arch/mn10300)
      Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com> (arch/mn10300)
      Cc: Kyle McMartin <kyle@mcmartin.ca> (arch/parisc)
      Cc: Helge Deller <deller@gmx.de> (arch/parisc)
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> (arch/parisc)
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> (arch/powerpc)
      Cc: Paul Mackerras <paulus@samba.org> (arch/powerpc)
      Cc: "David S. Miller" <davem@davemloft.net> (arch/sparc)
      Cc: Thomas Gleixner <tglx@linutronix.de> (arch/x86)
      Cc: Ingo Molnar <mingo@redhat.com> (arch/x86)
      Cc: "H. Peter Anvin" <hpa@zytor.com> (arch/x86)
      Cc: Arnd Bergmann <arnd@arndb.de> (include/asm-generic)
      Cc: Rusty Russell <rusty@rustcorp.com.au> ("Hard To Misuse" list)
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      597781f3
  17. 09 8月, 2010 2 次提交
  18. 08 8月, 2010 1 次提交
  19. 07 8月, 2010 1 次提交