Skip to content
  1. Aug 24, 2010
  2. Aug 23, 2010
  3. Aug 21, 2010
  4. Aug 20, 2010
  5. Aug 19, 2010
    • Borislav Petkov's avatar
      x86, hotplug: Serialize CPU hotplug to avoid bringup concurrency issues · d7c53c9e
      Borislav Petkov authored
      
      
      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: default avatarBorislav Petkov <borislav.petkov@amd.com>
      LKML-Reference: <20100819181029.GC17171@aftab>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      d7c53c9e
    • KUMANO Syuhei's avatar
      kprobes/x86: Fix the return address of multiple kretprobes · 737480a0
      KUMANO Syuhei authored
      
      
      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: default avatarKUMANO Syuhei <kumano.prog@gmail.com>
      Reviewed-by: default avatarMasami 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: default avatarIngo Molnar <mingo@elte.hu>
      737480a0
  6. Aug 18, 2010
    • H. Peter Anvin's avatar
      x86-32: Fix dummy trampoline-related inline stubs · 8848a910
      H. Peter Anvin authored
      
      
      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: default avatarH. 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
    • Tony Luck's avatar
      [IA64] Fix build error: conflicting types for ‘sys_execve’ · 145e5aa2
      Tony Luck authored
      
      
      arch/ia64/kernel/process.c:636: error: conflicting types for ‘sys_execve’
      
      commit d7627467
      Make do_execve() take a const filename pointer
      
      Missed the declaration of sys_execve in the ia64 asm/unistd.h (perhaps
      because there is no reason for it to be there ... it might be a left over
      from the COMPAT code?). Just delete the conflicting version.
      
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      145e5aa2
    • Joerg Roedel's avatar
      x86-32: Separate 1:1 pagetables from swapper_pg_dir · fd89a137
      Joerg Roedel authored
      
      
      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: default avatarJoerg Roedel <joerg.roedel@amd.com>
      LKML-Reference: <20100816123833.GB28147@aftab>
      Signed-off-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      fd89a137
    • Hans Rosenfeld's avatar
      x86, cpu: Fix regression in AMD errata checking code · 07a7795c
      Hans Rosenfeld authored
      
      
      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: default avatarHans Rosenfeld <hans.rosenfeld@amd.com>
      LKML-Reference: <1282141190-930137-1-git-send-email-hans.rosenfeld@amd.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      07a7795c
    • Zhang, Yanmin's avatar
      perf, x86: Fix Intel-nhm PMU programming errata workaround · 351af072
      Zhang, Yanmin authored
      
      
      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: default avatarZhang Yanmin <yanmin_zhang@linux.intel.com>
      Signed-off-by: default avatarPeter 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: default avatarIngo Molnar <mingo@elte.hu>
      351af072
    • Kulikov Vasiliy's avatar
      m68knommu: formatting of pointers in printk() · c7484cf4
      Kulikov Vasiliy authored
      
      
      arch/m68knommu/kernel/process.c: formatting of pointers in printk()
      
      Use %p instead of %08x in printk().
      
      Signed-off-by: default avatarKulikov Vasiliy <segooon@gmail.com>
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      c7484cf4
    • Jate Sujjavanich's avatar
      m68knommu: arch/m68k/include/asm/ide.h fix for nommu · dc6ae5e4
      Jate Sujjavanich authored
      
      
      The arch/m68k/include/asm/ide.h produces errors when the IDE driver is compiled for my 523x uClinux system under kernel. The header makes some redefines of operators not defined in the arch/m68k/include/asm/io_no.h header. There are no separate mmio and iospace defines.
      
      Signed-off-by: default avatarJate Sujjavanich <jsujjavanich@syntech-fuelmaster.com>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      dc6ae5e4
Loading