1. 15 6月, 2009 1 次提交
    • V
      x86: add hooks for kmemcheck · f8561296
      Vegard Nossum 提交于
      The hooks that we modify are:
      - Page fault handler (to handle kmemcheck faults)
      - Debug exception handler (to hide pages after single-stepping
        the instruction that caused the page fault)
      
      Also redefine memset() to use the optimized version if kmemcheck is
      enabled.
      
      (Thanks to Pekka Enberg for minimizing the impact on the page fault
      handler.)
      
      As kmemcheck doesn't handle MMX/SSE instructions (yet), we also disable
      the optimized xor code, and rely instead on the generic C implementation
      in order to avoid false-positive warnings.
      Signed-off-by: NVegard Nossum <vegardno@ifi.uio.no>
      
      [whitespace fixlet]
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      
      [rebased for mainline inclusion]
      Signed-off-by: NVegard Nossum <vegardno@ifi.uio.no>
      f8561296
  2. 13 6月, 2009 1 次提交
  3. 11 6月, 2009 1 次提交
  4. 10 6月, 2009 27 次提交
  5. 09 6月, 2009 3 次提交
    • C
      x86: Clear TS in irq_ts_save() when in an atomic section · 0b8c3d5a
      Chuck Ebbert 提交于
      The dynamic FPU context allocation changes caused the padlock driver
      to generate the below warning. Fix it by masking TS when doing padlock
      encryption operations in an atomic section.
      
      This solves:
      
      BUG: sleeping function called from invalid context at mm/slub.c:1602
      in_atomic(): 1, irqs_disabled(): 0, pid: 82, name: cryptomgr_test
      Pid: 82, comm: cryptomgr_test Not tainted 2.6.29.4-168.test7.fc11.x86_64 #1
      Call Trace:
      [<ffffffff8103ff16>] __might_sleep+0x10b/0x110
      [<ffffffff810cd3b2>] kmem_cache_alloc+0x37/0xf1
      [<ffffffff81018505>] init_fpu+0x49/0x8a
      [<ffffffff81012a83>] math_state_restore+0x3e/0xbc
      [<ffffffff813ac6d0>] do_device_not_available+0x9/0xb
      [<ffffffff810123ab>] device_not_available+0x1b/0x20
      [<ffffffffa001c066>] ? aes_crypt+0x66/0x74 [padlock_aes]
      [<ffffffff8119a51a>] ? blkcipher_walk_next+0x257/0x2e0
      [<ffffffff8119a731>] ? blkcipher_walk_first+0x18e/0x19d
      [<ffffffffa001c1fe>] aes_encrypt+0x9d/0xe5 [padlock_aes]
      [<ffffffffa0027253>] crypt+0x6b/0x114 [xts]
      [<ffffffffa001c161>] ? aes_encrypt+0x0/0xe5 [padlock_aes]
      [<ffffffffa001c161>] ? aes_encrypt+0x0/0xe5 [padlock_aes]
      [<ffffffffa0027390>] encrypt+0x49/0x4b [xts]
      [<ffffffff81199acc>] async_encrypt+0x3c/0x3e
      [<ffffffff8119dafc>] test_skcipher+0x1da/0x658
      [<ffffffff811979c3>] ? crypto_spawn_tfm+0x8e/0xb1
      [<ffffffff8119672d>] ? __crypto_alloc_tfm+0x11b/0x15f
      [<ffffffff811979c3>] ? crypto_spawn_tfm+0x8e/0xb1
      [<ffffffff81199dbe>] ? skcipher_geniv_init+0x2b/0x47
      [<ffffffff8119a905>] ? async_chainiv_init+0x5c/0x61
      [<ffffffff8119dfdd>] alg_test_skcipher+0x63/0x9b
      [<ffffffff8119e1bc>] alg_test+0x12d/0x175
      [<ffffffff8119c488>] cryptomgr_test+0x38/0x54
      [<ffffffff8119c450>] ? cryptomgr_test+0x0/0x54
      [<ffffffff8105c6c9>] kthread+0x4d/0x78
      [<ffffffff8101264a>] child_rip+0xa/0x20
      [<ffffffff81011f67>] ? restore_args+0x0/0x30
      [<ffffffff8105c67c>] ? kthread+0x0/0x78
      [<ffffffff81012640>] ? child_rip+0x0/0x20
      Signed-off-by: NChuck Ebbert <cebbert@redhat.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <20090609104050.50158cfe@dhcp-100-2-144.bos.redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0b8c3d5a
    • A
      x86: Detect use of extended APIC ID for AMD CPUs · 42937e81
      Andreas Herrmann 提交于
      Booting a 32-bit kernel on Magny-Cours results in the following panic:
      
        ...
        Using APIC driver default
        ...
        Overriding APIC driver with bigsmp
        ...
        Getting VERSION: 80050010
        Getting VERSION: 80050010
        Getting ID: 10000000
        Getting ID: ef000000
        Getting LVT0: 700
        Getting LVT1: 10000
        Kernel panic - not syncing: Boot APIC ID in local APIC unexpected (16 vs 0)
        Pid: 1, comm: swapper Not tainted 2.6.30-rcX #2
        Call Trace:
         [<c05194da>] ? panic+0x38/0xd3
         [<c0743102>] ? native_smp_prepare_cpus+0x259/0x31f
         [<c073b19d>] ? kernel_init+0x3e/0x141
         [<c073b15f>] ? kernel_init+0x0/0x141
         [<c020325f>] ? kernel_thread_helper+0x7/0x10
      
      The reason is that default_get_apic_id handled extension of local APIC
      ID field just in case of XAPIC.
      
      Thus for this AMD CPU, default_get_apic_id() returns 0 and
      bigsmp_get_apic_id() returns 16 which leads to the respective kernel
      panic.
      
      This patch introduces a Linux specific feature flag to indicate
      support for extended APIC id (8 bits instead of 4 bits width) and sets
      the flag on AMD CPUs if applicable.
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Cc: <stable@kernel.org>
      LKML-Reference: <20090608135509.GA12431@alberich.amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      42937e81
    • J
      x86, UV: Fix macros for multiple coherency domains · c4ed3f04
      Jack Steiner 提交于
      Fix bug in the SGI UV macros that support systems with multiple
      coherency domains.  The macros used for referencing global MMR
      (chipset registers) are failing to correctly "or" the NASID
      (node identifier) bits that reside above M+N. These high bits
      are supplied automatically by the chipset for memory accesses
      coming from the processor socket.
      
      However, the bits must be present for references to the special
      global MMR space used to map chipset registers. (See uv_hub.h
      for more details ...)
      
      The bug results in references to invalid/incorrect nodes.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Cc: <stable@kernel.org>
      LKML-Reference: <20090608154405.GA16395@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c4ed3f04
  6. 07 6月, 2009 2 次提交
  7. 03 6月, 2009 2 次提交
    • C
      x86: Fix UV BAU activation descriptor init · 0e2595cd
      Cliff Wickman 提交于
      The UV tlb shootdown code has a serious initialization error.
      
      An array of structures [32*8] is initialized as if it were [32].
      The array is indexed by (cpu number on the blade)*8, so the short
      initialization works for up to 4 cpus on a blade.
      But above that, we provide an invalid opcode to the hub's
      broadcast assist unit.
      
      This patch changes the allocation of the array to use its symbolic
      dimensions for better clarity. And initializes all 32*8 entries.
      
      Shortened 'UV_ACTIVATION_DESCRIPTOR_SIZE' to 'UV_ADP_SIZE' per Ingo's
      recommendation.
      
      Tested on the UV simulator.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Cc: <stable@kernel.org>
      LKML-Reference: <E1M6lZR-0007kV-Aq@eag09.americas.sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0e2595cd
    • Y
      perf_counter/x86: Remove the IRQ (non-NMI) handling bits · a3288106
      Yong Wang 提交于
      Remove the IRQ (non-NMI) handling bits as NMI will be used always.
      Signed-off-by: NYong Wang <yong.y.wang@intel.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: John Kacur <jkacur@redhat.com>
      LKML-Reference: <20090603051255.GA2791@ywang-moblin2.bj.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a3288106
  8. 29 5月, 2009 3 次提交