1. 28 1月, 2013 12 次提交
  2. 25 1月, 2013 1 次提交
    • A
      x86/MSI: Support multiple MSIs in presense of IRQ remapping · 51906e77
      Alexander Gordeev 提交于
      The MSI specification has several constraints in comparison with
      MSI-X, most notable of them is the inability to configure MSIs
      independently. As a result, it is impossible to dispatch
      interrupts from different queues to different CPUs. This is
      largely devalues the support of multiple MSIs in SMP systems.
      
      Also, a necessity to allocate a contiguous block of vector
      numbers for devices capable of multiple MSIs might cause a
      considerable pressure on x86 interrupt vector allocator and
      could lead to fragmentation of the interrupt vectors space.
      
      This patch overcomes both drawbacks in presense of IRQ remapping
      and lets devices take advantage of multiple queues and per-IRQ
      affinity assignments.
      Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Matthew Wilcox <willy@linux.intel.com>
      Cc: Jeff Garzik <jgarzik@pobox.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/c8bd86ff56b5fc118257436768aaa04489ac0a4c.1353324359.git.agordeev@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      51906e77
  3. 24 1月, 2013 2 次提交
  4. 23 1月, 2013 2 次提交
    • O
      ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL · 9899d11f
      Oleg Nesterov 提交于
      putreg() assumes that the tracee is not running and pt_regs_access() can
      safely play with its stack.  However a killed tracee can return from
      ptrace_stop() to the low-level asm code and do RESTORE_REST, this means
      that debugger can actually read/modify the kernel stack until the tracee
      does SAVE_REST again.
      
      set_task_blockstep() can race with SIGKILL too and in some sense this
      race is even worse, the very fact the tracee can be woken up breaks the
      logic.
      
      As Linus suggested we can clear TASK_WAKEKILL around the arch_ptrace()
      call, this ensures that nobody can ever wakeup the tracee while the
      debugger looks at it.  Not only this fixes the mentioned problems, we
      can do some cleanups/simplifications in arch_ptrace() paths.
      
      Probably ptrace_unfreeze_traced() needs more callers, for example it
      makes sense to make the tracee killable for oom-killer before
      access_process_vm().
      
      While at it, add the comment into may_ptrace_stop() to explain why
      ptrace_stop() still can't rely on SIGKILL and signal_pending_state().
      Reported-by: NSalman Qazi <sqazi@google.com>
      Reported-by: NSuleiman Souhlal <suleiman@google.com>
      Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9899d11f
    • W
      arm64: elf: fix core dumping to match what glibc expects · 9cf2b72b
      Will Deacon 提交于
      The kernel's internal definition of ELF_NGREG uses struct pt_regs, which
      means that we disagree with userspace on the size of coredumps since
      glibc correctly uses the user-visible struct user_pt_regs.
      
      This patch fixes our ELF_NGREG definition to use struct user_pt_regs
      and introduces our own ELF_CORE_COPY_REGS to convert between the user
      and kernel structure definitions.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      9cf2b72b
  5. 21 1月, 2013 1 次提交
  6. 18 1月, 2013 2 次提交
  7. 17 1月, 2013 1 次提交
    • A
      xen: Fix stack corruption in xen_failsafe_callback for 32bit PVOPS guests. · 9174adbe
      Andrew Cooper 提交于
      This fixes CVE-2013-0190 / XSA-40
      
      There has been an error on the xen_failsafe_callback path for failed
      iret, which causes the stack pointer to be wrong when entering the
      iret_exc error path.  This can result in the kernel crashing.
      
      In the classic kernel case, the relevant code looked a little like:
      
              popl %eax      # Error code from hypervisor
              jz 5f
              addl $16,%esp
              jmp iret_exc   # Hypervisor said iret fault
      5:      addl $16,%esp
                             # Hypervisor said segment selector fault
      
      Here, there are two identical addls on either option of a branch which
      appears to have been optimised by hoisting it above the jz, and
      converting it to an lea, which leaves the flags register unaffected.
      
      In the PVOPS case, the code looks like:
      
              popl_cfi %eax         # Error from the hypervisor
              lea 16(%esp),%esp     # Add $16 before choosing fault path
              CFI_ADJUST_CFA_OFFSET -16
              jz 5f
              addl $16,%esp         # Incorrectly adjust %esp again
              jmp iret_exc
      
      It is possible unprivileged userspace applications to cause this
      behaviour, for example by loading an LDT code selector, then changing
      the code selector to be not-present.  At this point, there is a race
      condition where it is possible for the hypervisor to return back to
      userspace from an interrupt, fault on its own iret, and inject a
      failsafe_callback into the kernel.
      
      This bug has been present since the introduction of Xen PVOPS support
      in commit 5ead97c8 (xen: Core Xen implementation), in 2.6.23.
      Signed-off-by: NFrediano Ziglio <frediano.ziglio@citrix.com>
      Signed-off-by: NAndrew Cooper <andrew.cooper3@citrix.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      9174adbe
  8. 16 1月, 2013 4 次提交
  9. 14 1月, 2013 6 次提交
  10. 13 1月, 2013 3 次提交
  11. 12 1月, 2013 3 次提交
  12. 11 1月, 2013 3 次提交