linux.git/arch/powerpc, branch v3.14

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm

2014-03-18T18:32:08+00:00

Pull another kvm fix from Paolo Bonzini:
 "A fix for a PowerPC bug that was introduced during the 3.14 merge
  window"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: PPC: Book3S HV: Fix register usage when loading/saving VRSAVE
  KVM: PPC: Book3S HV: Remove bogus duplicate code

KVM: PPC: Book3S HV: Fix register usage when loading/saving VRSAVE

2014-03-13T09:47:01+00:00

Commit 595e4f7e697e ("KVM: PPC: Book3S HV: Use load/store_fp_state
functions in HV guest entry/exit") changed the register usage in
kvmppc_save_fp() and kvmppc_load_fp() but omitted changing the
instructions that load and save VRSAVE.  The result is that the
VRSAVE value was loaded from a constant address, and saved to a
location past the end of the vcpu struct, causing host kernel
memory corruption and various kinds of host kernel crashes.

This fixes the problem by using register r31, which contains the
vcpu pointer, instead of r3 and r4.

Signed-off-by: Paul Mackerras 
Signed-off-by: Paolo Bonzini

KVM: PPC: Book3S HV: Remove bogus duplicate code

2014-03-13T09:46:52+00:00

Commit 7b490411c37f ("KVM: PPC: Book3S HV: Add new state for
transactional memory") incorrectly added some duplicate code to the
guest exit path because I didn't manage to clean up after a rebase
correctly.  This removes the extraneous material.  The presence of
this extraneous code causes host crashes whenever a guest is run.

Signed-off-by: Paul Mackerras 
Signed-off-by: Paolo Bonzini

mm: fix GFP_THISNODE callers and clarify

2014-03-11T00:26:19+00:00

GFP_THISNODE is for callers that implement their own clever fallback to
remote nodes.  It restricts the allocation to the specified node and
does not invoke reclaim, assuming that the caller will take care of it
when the fallback fails, e.g.  through a subsequent allocation request
without GFP_THISNODE set.

However, many current GFP_THISNODE users only want the node exclusive
aspect of the flag, without actually implementing their own fallback or
triggering reclaim if necessary.  This results in things like page
migration failing prematurely even when there is easily reclaimable
memory available, unless kswapd happens to be running already or a
concurrent allocation attempt triggers the necessary reclaim.

Convert all callsites that don't implement their own fallback strategy
to __GFP_THISNODE.  This restricts the allocation a single node too, but
at the same time allows the allocator to enter the slowpath, wake
kswapd, and invoke direct reclaim if necessary, to make the allocation
happen when memory is full.

Signed-off-by: Johannes Weiner 
Acked-by: Rik van Riel 
Cc: Jan Stancek 
Cc: Mel Gorman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

powerpc: Align p_dyn, p_rela and p_st symbols

2014-03-07T02:50:19+00:00

The 64bit relocation code places a few symbols in the text segment.
These symbols are only 4 byte aligned where they need to be 8 byte
aligned. Add an explicit alignment.

Signed-off-by: Anton Blanchard 
Cc: stable@vger.kernel.org
Tested-by: Laurent Dufour 
Signed-off-by: Benjamin Herrenschmidt

powerpc/tm: Fix crash when forking inside a transaction

2014-03-07T02:50:15+00:00

When we fork/clone we currently don't copy any of the TM state to the new
thread.  This results in a TM bad thing (program check) when the new process is
switched in as the kernel does a tmrechkpt with TEXASR FS not set.  Also, since
R1 is from userspace, we trigger the bad kernel stack pointer detection.  So we
end up with something like this:

   Bad kernel stack pointer 0 at c0000000000404fc
   cpu 0x2: Vector: 700 (Program Check) at [c00000003ffefd40]
       pc: c0000000000404fc: restore_gprs+0xc0/0x148
       lr: 0000000000000000
       sp: 0
      msr: 9000000100201030
     current = 0xc000001dd1417c30
     paca    = 0xc00000000fe00800   softe: 0        irq_happened: 0x01
       pid   = 0, comm = swapper/2
   WARNING: exception is not recoverable, can't continue

The below fixes this by flushing the TM state before we copy the task_struct to
the clone.  To do this we go through the tmreclaim patch, which removes the
checkpointed registers from the CPU and transitions the CPU out of TM suspend
mode.  Hence we need to call tmrechkpt after to restore the checkpointed state
and the TM mode for the current task.

To make this fail from userspace is simply:
	tbegin
	li	r0, 2
	sc
	

Kudos to Adhemerval Zanella Neto for finding this.

Signed-off-by: Michael Neuling 
cc: Adhemerval Zanella Neto 
cc: stable@vger.kernel.org
Signed-off-by: Benjamin Herrenschmidt

powerpc/powernv: Fix indirect XSCOM unmangling

2014-02-28T08:15:49+00:00

We need to unmangle the full address, not just the register
number, and we also need to support the real indirect bit
being set for in-kernel uses.

Signed-off-by: Benjamin Herrenschmidt 
CC:  [v3.13]

powerpc/powernv: Fix opal_xscom_{read,write} prototype

2014-02-28T08:15:48+00:00

The OPAL firmware functions opal_xscom_read and opal_xscom_write
take a 64-bit argument for the XSCOM (PCB) address in order to
support the indirect mode on P8.

Signed-off-by: Benjamin Herrenschmidt 
CC:  [v3.13]

powerpc/powernv: Refactor PHB diag-data dump

2014-02-28T07:43:19+00:00

As Ben suggested, the patch prints PHB diag-data with multiple
fields in one line and omits the line if the fields of that
line are all zero.

With the patch applied, the PHB3 diag-data dump looks like:

PHB3 PHB#3 Diag-data (Version: 1)

  brdgCtl:     00000002
  RootSts:     0000000f 00400000 b0830008 00100147 00002000
  nFir:        0000000000000000 0030006e00000000 0000000000000000
  PhbSts:      0000001c00000000 0000000000000000
  Lem:         0000000000100000 42498e327f502eae 0000000000000000
  InAErr:      8000000000000000 8000000000000000 0402030000000000 0000000000000000
  PE[  8] A/B: 8480002b00000000 8000000000000000

[ The current diag data is so big that it overflows the printk
  buffer pretty quickly in cases when we get a handful of errors
  at once which can happen. --BenH
]

Signed-off-by: Gavin Shan 
CC: 
Signed-off-by: Benjamin Herrenschmidt

powerpc/powernv: Dump PHB diag-data immediately

2014-02-28T07:43:10+00:00

The PHB diag-data is important to help locating the root cause for
EEH errors such as frozen PE or fenced PHB. However, the EEH core
enables IO path by clearing part of HW registers before collecting
this data causing it to be corrupted.

This patch fixes this by dumping the PHB diag-data immediately when
frozen/fenced state on PE or PHB is detected for the first time in
eeh_ops::get_state() or next_error() backend.

Signed-off-by: Gavin Shan 
CC: 
Signed-off-by: Benjamin Herrenschmidt