linux-stable.git/arch, branch v3.9.5

powerpc/pseries: Always enable CONFIG_HOTPLUG_CPU on PSERIES SMP

2013-06-07T19:53:22+00:00

commit f274ef8747d3be649bba8708696fb31cb00fa75a upstream.

Adam Lackorzynski reported the following build failure on
!CONFIG_HOTPLUG_CPU configuration:

  CC      arch/powerpc/kernel/rtas.o
arch/powerpc/kernel/rtas.c: In function ‘rtas_cpu_state_change_mask’:
arch/powerpc/kernel/rtas.c:843:4: error: implicit declaration of function ‘cpu_down’ [-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
make[1]: *** [arch/powerpc/kernel/rtas.o] Error 1
make: *** [arch/powerpc/kernel] Error 2

The build fails because cpu_down() is defined only under CONFIG_HOTPLUG_CPU.

Looking further, the mobility code in pseries is one of the call-sites which
uses rtas_ibm_suspend_me(), which in turn calls rtas_cpu_state_change_mask().
And the mobility code is unconditionally compiled-in (it does not fall under
any Kconfig option). And commit 120496ac (powerpc: Bring all threads online
prior to migration/hibernation) which introduced this build regression is
critical for the proper functioning of the migration code. So it appears
that the only solution to this problem is to enable CONFIG_HOTPLUG_CPU if
SMP is enabled on PPC_PSERIES platforms. So make that change in the Kconfig.

Reported-by: Adam Lackorzynski 
Signed-off-by: Srivatsa S. Bhat 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

KVM: fix sil/dil/bpl/spl in the mod/rm fields

2013-06-07T19:53:21+00:00

commit 8acb42070ec4c87a9baab5c7bac626030d5bef28 upstream.

The x86-64 extended low-byte registers were fetched correctly from reg,
but not from mod/rm.

This fixes another bug in the boot of RHEL5.9 64-bit, but it is still
not enough.

Signed-off-by: Paolo Bonzini 
Signed-off-by: Gleb Natapov 
Signed-off-by: Greg Kroah-Hartman

KVM: Emulate multibyte NOP

2013-06-07T19:53:21+00:00

commit 103f98ea64a1b0a67d8a1b23070b4db3533db2b8 upstream.

This is encountered when booting RHEL5.9 64-bit.  There is another bug
after this one that is not a simple emulation failure, but this one lets
the boot proceed a bit.

Signed-off-by: Paolo Bonzini 
Signed-off-by: Gleb Natapov 
Signed-off-by: Greg Kroah-Hartman

powerpc/tm: Move TM abort cause codes to uapi

2013-06-07T19:53:20+00:00

commit b75c100ef24894bd2c8b52e123bcc5f191c5d9fd upstream.

These cause codes are usable by userspace, so let's export to uapi.

Signed-off-by: Michael Neuling 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

powerpc/tm: Abort on emulation and alignment faults

2013-06-07T19:53:20+00:00

commit 6ce6c629fd8254b3177650de99699682ff7f6707 upstream.

If we are emulating an instruction inside an active user transaction that
touches memory, the kernel can't emulate it as it operates in transactional
suspend context.  We need to abort these transactions and send them back to
userspace for the hardware to rollback.

We can service these if the user transaction is in suspend mode, since the
kernel will operate in the same suspend context.

This adds a check to all alignment faults and to specific instruction
emulations (only string instructions for now).  If the user process is in an
active (non-suspended) transaction, we abort the transaction go back to
userspace allowing the HW to roll back the transaction and tell the user of the
failure.  This also adds new tm abort cause codes to report the reason of the
persistent error to the user.

Crappy test case here http://neuling.org/devel/junkcode/aligntm.c

Signed-off-by: Michael Neuling 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

powerpc/tm: Fix userspace stack corruption on signal delivery for active transactions

2013-06-07T19:53:19+00:00

commit 2b3f8e87cf99a33fb6faf5026d7147748bbd77b6 upstream.

When in an active transaction that takes a signal, we need to be careful with
the stack.  It's possible that the stack has moved back up after the tbegin.
The obvious case here is when the tbegin is called inside a function that
returns before a tend.  In this case, the stack is part of the checkpointed
transactional memory state.  If we write over this non transactionally or in
suspend, we are in trouble because if we get a tm abort, the program counter
and stack pointer will be back at the tbegin but our in memory stack won't be
valid anymore.

To avoid this, when taking a signal in an active transaction, we need to use
the stack pointer from the checkpointed state, rather than the speculated
state.  This ensures that the signal context (written tm suspended) will be
written below the stack required for the rollback.  The transaction is aborted
becuase of the treclaim, so any memory written between the tbegin and the
signal will be rolled back anyway.

For signals taken in non-TM or suspended mode, we use the
normal/non-checkpointed stack pointer.

Tested with 64 and 32 bit signals

Signed-off-by: Michael Neuling 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

powerpc/tm: Make room for hypervisor in abort cause codes

2013-06-07T19:53:19+00:00

commit 35f7097fcedec63fcba1852dbee96f74a2d90878 upstream.

PAPR carves out 0xff-0xe0 for hypervisor use of transactional memory software
abort cause codes.  Unfortunately we don't respect this currently.

Below fixes this to move our cause codes to below this region.

Signed-off-by: Michael Neuling 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

powerpc/32bit:Store temporary result in r0 instead of r8

2013-06-07T19:53:18+00:00

commit f7b3367774f92a688d39ed767f0ae9b93af7873a upstream.

Commit a9c4e541ea9b22944da356f2a9258b4eddcc953b
"powerpc/kprobe: Complete kprobe and migrate exception frame"
introduced a regression:

While returning from exception handling in case of PREEMPT enabled,
_TIF_NEED_RESCHED bit is checked in TI_FLAGS (thread_info flag) of current
task. Only if this bit is set, it should continue with the process of
calling preempt_schedule_irq() to schedule highest priority task if
available.

Current code assumes that r8 contains TI_FLAGS and check this for
_TIF_NEED_RESCHED, but as r8 is modified in the code which executes before
this check, r8 no longer contains the expected TI_FLAGS information.

As a result check for comparison with _TIF_NEED_RESCHED was failing even if
NEED_RESCHED bit is set in the current thread_info flag. Due to this,
preempt_schedule_irq() and in turn scheduler was not getting called even if
highest priority task is ready for execution.

So, store temporary results in r0 instead of r8 to prevent r8 from getting
modified as subsequent code is dependent on its value.

Signed-off-by: Priyanka Jain 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

s390/pgtable: Fix check for pgste/storage key handling

2013-06-07T19:53:05+00:00

commit b56433cb782d1cc7e44fc46d2ce3917fa75d2236 upstream.

pte_present might return true on PAGE_TYPE_NONE, even if
the invalid bit is on. Modify the existing check of the
pgste functions to avoid crashes.

[ Martin Schwidefsky: added ptep_modify_prot_[start|commit] bits ]

Reported-by: Martin Schwidefky 
Signed-off-by: Christian Borntraeger 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

m68k/mac: Fix unexpected interrupt with CONFIG_EARLY_PRINTK

2013-06-07T19:53:05+00:00

commit df66834a43c461de2565c45d815288ba1c0def37 upstream.

The present code does not wait for the SCC to finish resetting itself
before trying to initialise the device. The result is that the SCC
interrupt sources become enabled (if they weren't already). This leads to
an early boot crash (unexpected interrupt) given CONFIG_EARLY_PRINTK. Fix
this by adding a delay. A successful reset disables the interrupt sources.

Also, after the reset for channel A setup, the SCC then gets a second
reset for channel B setup which leaves channel A uninitialised again. Fix
this by performing the reset only once.

Signed-off-by: Finn Thain 
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Greg Kroah-Hartman