1. 05 3月, 2009 3 次提交
    • D
      x86, math-emu: fix init_fpu for task != current · ab9e1858
      Daniel Glöckner 提交于
      Impact: fix math-emu related crash while using GDB/ptrace
      
      init_fpu() calls finit to initialize a task's xstate, while finit always
      works on the current task. If we use PTRACE_GETFPREGS on another
      process and both processes did not already use floating point, we get
      a null pointer exception in finit.
      
      This patch creates a new function finit_task that takes a task_struct
      parameter. finit becomes a wrapper that simply calls finit_task with
      current. On the plus side this avoids many calls to get_current which
      would each resolve to an inline assembler mov instruction.
      
      An empty finit_task has been added to i387.h to avoid linker errors in
      case the compiler still emits the call in init_fpu when
      CONFIG_MATH_EMULATION is not defined.
      
      The declaration of finit in i387.h has been removed as the remaining
      code using this function gets its prototype from fpu_proto.h.
      Signed-off-by: NDaniel Glöckner <dg@emlix.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: "Pallipadi Venkatesh" <venkatesh.pallipadi@intel.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Bill Metzenthen <billm@melbpc.org.au>
      LKML-Reference: <E1Lew31-0004il-Fg@mailer.emlix.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ab9e1858
    • H
      x86: EFI: Back efi_ioremap with init_memory_mapping instead of FIX_MAP · dd39ecf5
      Huang Ying 提交于
      Impact: Fix boot failure on EFI system with large runtime memory range
      
      Brian Maly reported that some EFI system with large runtime memory
      range can not boot. Because the FIX_MAP used to map runtime memory
      range is smaller than run time memory range.
      
      This patch fixes this issue by re-implement efi_ioremap() with
      init_memory_mapping().
      Reported-and-tested-by: NBrian Maly <bmaly@redhat.com>
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Cc: Brian Maly <bmaly@redhat.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      LKML-Reference: <1236135513.6204.306.camel@yhuang-dev.sh.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      dd39ecf5
    • B
      x86: fix DMI on EFI · ff0c0874
      Brian Maly 提交于
      Impact: reactivate DMI quirks on EFI hardware
      
      DMI tables are loaded by EFI, so the dmi calls must happen after
      efi_init() and not before.
      
      Currently Apple hardware uses DMI to determine the framebuffer mappings
      for efifb. Without DMI working you also have no video on MacBook Pro.
      
      This patch resolves the DMI issue for EFI hardware (DMI is now properly
      detected at boot), and additionally efifb now loads on Apple hardware
      (i.e. video works).
      Signed-off-by: NBrian Maly <bmaly@redhat>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Cc: ying.huang@intel.com
      LKML-Reference: <49ADEDA3.1030406@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      
       arch/x86/kernel/setup.c |    5 +++--
       1 file changed, 3 insertions(+), 2 deletions(-)
      ff0c0874
  2. 04 3月, 2009 12 次提交
  3. 03 3月, 2009 24 次提交
  4. 02 3月, 2009 1 次提交
    • P
      x86 mmiotrace: fix race with release_kmmio_fault_page() · 340430c5
      Pekka Paalanen 提交于
      There was a theoretical possibility to a race between arming a page in
      post_kmmio_handler() and disarming the page in
      release_kmmio_fault_page():
      
      cpu0                             cpu1
      ------------------------------------------------------------------
      mmiotrace shutdown
      enter release_kmmio_fault_page
                                       fault on the page
                                       disarm the page
      disarm the page
                                       handle the MMIO access
                                       re-arm the page
      put the page on release list
      remove_kmmio_fault_pages()
                                       fault on the page
                                       page not known to mmiotrace
                                       fall back to do_page_fault()
                                       *KABOOM*
      
      (This scenario also shows the double disarm case which is allowed.)
      
      Fixed by acquiring kmmio_lock in post_kmmio_handler() and checking
      if the page is being released from mmiotrace.
      Signed-off-by: NPekka Paalanen <pq@iki.fi>
      Cc: Stuart Bennett <stuart@freedesktop.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      340430c5