1. 30 10月, 2013 7 次提交
  2. 29 10月, 2013 1 次提交
  3. 19 10月, 2013 2 次提交
  4. 17 10月, 2013 1 次提交
  5. 11 10月, 2013 22 次提交
  6. 25 9月, 2013 2 次提交
    • B
      powerpc: Remove ksp_limit on ppc64 · cbc9565e
      Benjamin Herrenschmidt 提交于
      We've been keeping that field in thread_struct for a while, it contains
      the "limit" of the current stack pointer and is meant to be used for
      detecting stack overflows.
      
      It has a few problems however:
      
       - First, it was never actually *used* on 64-bit. Set and updated but
      not actually exploited
      
       - When switching stack to/from irq and softirq stacks, it's update
      is racy unless we hard disable interrupts, which is costly. This
      is fine on 32-bit as we don't soft-disable there but not on 64-bit.
      
      Thus rather than fixing 2 in order to implement 1 in some hypothetical
      future, let's remove the code completely from 64-bit. In order to avoid
      a clutter of ifdef's, we remove the updates from C code completely
      during interrupt stack switching, and instead maintain it from the
      asm helper that is used to do the stack switching in the first place.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      cbc9565e
    • B
      powerpc/irq: Run softirqs off the top of the irq stack · 0366a1c7
      Benjamin Herrenschmidt 提交于
      Nowadays, irq_exit() calls __do_softirq() pretty much directly
      instead of calling do_softirq() which switches to the decicated
      softirq stack.
      
      This has lead to observed stack overflows on powerpc since we call
      irq_enter() and irq_exit() outside of the scope that switches to
      the irq stack.
      
      This fixes it by moving the stack switching up a level, making
      irq_enter() and irq_exit() run off the irq stack.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      0366a1c7
  7. 05 9月, 2013 1 次提交
  8. 28 8月, 2013 1 次提交
    • P
      KVM: PPC: Book3S PR: Make instruction fetch fallback work for system calls · 8b23de29
      Paul Mackerras 提交于
      It turns out that if we exit the guest due to a hcall instruction (sc 1),
      and the loading of the instruction in the guest exit path fails for any
      reason, the call to kvmppc_ld() in kvmppc_get_last_inst() fetches the
      instruction after the hcall instruction rather than the hcall itself.
      This in turn means that the instruction doesn't get recognized as an
      hcall in kvmppc_handle_exit_pr() but gets passed to the guest kernel
      as a sc instruction.  That usually results in the guest kernel getting
      a return code of 38 (ENOSYS) from an hcall, which often triggers a
      BUG_ON() or other failure.
      
      This fixes the problem by adding a new variant of kvmppc_get_last_inst()
      called kvmppc_get_last_sc(), which fetches the instruction if necessary
      from pc - 4 rather than pc.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      8b23de29
  9. 27 8月, 2013 3 次提交