1. 09 Sep, 2012 24 commits
  2. 07 Sep, 2012 10 commits
  3. 06 Sep, 2012 3 commits
  4. 05 Sep, 2012 3 commits
    • Benjamin Herrenschmidt's avatar
      powerpc: Don't use __put_user() in patch_instruction · 636802ef
      Benjamin Herrenschmidt authored
      patch_instruction() can be called very early on ppc32, when the kernel
      isn't yet running at it's linked address. That can cause the !
      is_kernel_addr() test in __put_user() to trip and call might_sleep()
      which is very bad at that point during boot.
      
      Use a lower level function instead for now, at least until we get to
      rework ppc32 boot process to do the code patching later, like ppc64
      does.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      636802ef
    • Paul Mackerras's avatar
      powerpc: Make sure IPI handlers see data written by IPI senders · 9fb1b36c
      Paul Mackerras authored
      We have been observing hangs, both of KVM guest vcpu tasks and more
      generally, where a process that is woken doesn't properly wake up and
      continue to run, but instead sticks in TASK_WAKING state.  This
      happens because the update of rq->wake_list in ttwu_queue_remote()
      is not ordered with the update of ipi_message in
      smp_muxed_ipi_message_pass(), and the reading of rq->wake_list in
      scheduler_ipi() is not ordered with the reading of ipi_message in
      smp_ipi_demux().  Thus it is possible for the IPI receiver not to see
      the updated rq->wake_list and therefore conclude that there is nothing
      for it to do.
      
      In order to make sure that anything done before smp_send_reschedule()
      is ordered before anything done in the resulting call to scheduler_ipi(),
      this adds barriers in smp_muxed_message_pass() and smp_ipi_demux().
      The barrier in smp_muxed_message_pass() is a full barrier to ensure that
      there is a full ordering between the smp_send_reschedule() caller and
      scheduler_ipi().  In smp_ipi_demux(), we use xchg() rather than
      xchg_local() because xchg() includes release and acquire barriers.
      Using xchg() rather than xchg_local() makes sense given that
      ipi_message is not just accessed locally.
      
      This moves the barrier between setting the message and calling the
      cause_ipi() function into the individual cause_ipi implementations.
      Most of them -- those that used outb, out_8 or similar -- already had
      a full barrier because out_8 etc. include a sync before the MMIO
      store.  This adds an explicit barrier in the two remaining cases.
      
      These changes made no measurable difference to the speed of IPIs as
      measured using a simple ping-pong latency test across two CPUs on
      different cores of a POWER7 machine.
      
      The analysis of the reason why processes were not waking up properly
      is due to Milton Miller.
      
      Cc: stable@vger.kernel.org # v3.0+
      Reported-by: default avatarMilton Miller <miltonm@bga.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      9fb1b36c
    • Anton Blanchard's avatar
      powerpc: Restore correct DSCR in context switch · 71433285
      Anton Blanchard authored
      During a context switch we always restore the per thread DSCR value.
      If we aren't doing explicit DSCR management
      (ie thread.dscr_inherit == 0) and the default DSCR changed while
      the process has been sleeping we end up with the wrong value.
      
      Check thread.dscr_inherit and select the default DSCR or per thread
      DSCR as required.
      
      This was found with the following test case, when running with
      more threads than CPUs (ie forcing context switching):
      
      http://ozlabs.org/~anton/junkcode/dscr_default_test.c
      
      With the four patches applied I can run a combination of all
      test cases successfully at the same time:
      
      http://ozlabs.org/~anton/junkcode/dscr_default_test.c
      http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c
      http://ozlabs.org/~anton/junkcode/dscr_inherit_test.cSigned-off-by: default avatarAnton Blanchard <anton@samba.org>
      Cc: <stable@kernel.org> # 3.0+
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      71433285