1. 31 10月, 2013 2 次提交
  2. 30 10月, 2013 7 次提交
  3. 29 10月, 2013 1 次提交
  4. 19 10月, 2013 2 次提交
  5. 17 10月, 2013 1 次提交
  6. 11 10月, 2013 21 次提交
  7. 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
  8. 05 9月, 2013 1 次提交
  9. 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
  10. 27 8月, 2013 2 次提交
    • B
      powerpc/powernv: Return secondary CPUs to firmware on kexec · 13906db6
      Benjamin Herrenschmidt 提交于
      With OPAL v3 we can return secondary CPUs to firmware on kexec. This
      allows firmware to do various cleanups making things generally more
      reliable, and will enable the "new" kernel to call OPAL to perform
      some reconfiguration tasks early on that can only be done while
      all the CPUs are in firmware.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      13906db6
    • P
      powerpc: Work around gcc miscompilation of __pa() on 64-bit · bdbc29c1
      Paul Mackerras 提交于
      On 64-bit, __pa(&static_var) gets miscompiled by recent versions of
      gcc as something like:
      
              addis 3,2,.LANCHOR1+4611686018427387904@toc@ha
              addi 3,3,.LANCHOR1+4611686018427387904@toc@l
      
      This ends up effectively ignoring the offset, since its bottom 32 bits
      are zero, and means that the result of __pa() still has 0xC in the top
      nibble.  This happens with gcc 4.8.1, at least.
      
      To work around this, for 64-bit we make __pa() use an AND operator,
      and for symmetry, we make __va() use an OR operator.  Using an AND
      operator rather than a subtraction ends up with slightly shorter code
      since it can be done with a single clrldi instruction, whereas it
      takes three instructions to form the constant (-PAGE_OFFSET) and add
      it on.  (Note that MEMORY_START is always 0 on 64-bit.)
      
      CC: <stable@vger.kernel.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      bdbc29c1