linux-toradex.git/arch/powerpc/kernel/process.c, branch v4.9.121

powerpc: Fix VSX enabling/flushing to also test MSR_FP and MSR_VEC

2017-08-25T00:12:20+00:00

commit 5a69aec945d27e78abac9fd032533d3aaebf7c1e upstream.

VSX uses a combination of the old vector registers, the old FP
registers and new "second halves" of the FP registers.

Thus when we need to see the VSX state in the thread struct
(flush_vsx_to_thread()) or when we'll use the VSX in the kernel
(enable_kernel_vsx()) we need to ensure they are all flushed into
the thread struct if either of them is individually enabled.

Unfortunately we only tested if the whole VSX was enabled, not if they
were individually enabled.

Fixes: 72cd7b44bc99 ("powerpc: Uncomment and make enable_kernel_vsx() routine available")
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

powerpc/kernel: Initialize load_tm on task creation

2017-06-14T13:06:03+00:00

commit 7f22ced4377628074e2ac25f41a88f98eb3b03f1 upstream.

Currently tsk->thread.load_tm is not initialized in the task creation
and can contain garbage on a new task.

This is an undesired behaviour, since it affects the timing to enable
and disable the transactional memory laziness (disabling and enabling
the MSR TM bit, which affects TM reclaim and recheckpoint in the
scheduling process).

Fixes: 5d176f751ee3 ("powerpc: tm: Enable transactional memory (TM) lazily for userspace")
Signed-off-by: Breno Leitao 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

powerpc/kernel: Fix FP and vector register restoration

2017-06-14T13:06:03+00:00

commit 1195892c091a15cc862f4e202482a36adc924e12 upstream.

Currently tsk->thread->load_vec and load_fp are not initialized during
task creation, which can lead to garbage values in these variables (non-zero
values).

These variables will be checked later in restore_math() to validate if the
FP and vector registers are being utilized. Since these values might be
non-zero, the restore_math() will continue to save the FP and vectors even if
they were never utilized by the userspace application. load_fp and load_vec
counters will then overflow (they wrap at 255) and the FP and Altivec will be
finally disabled, but before that condition is reached (counter overflow)
several context switches will have restored FP and vector registers without
need, causing a performance degradation.

Fixes: 70fe3d980f5f ("powerpc: Restore FPU/VEC/VSX if previously used")
Signed-off-by: Breno Leitao 
Signed-off-by: Gustavo Romero 
Acked-by: Anton Blanchard 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

powerpc/tm: Fix FP and VMX register corruption

2017-05-25T13:44:43+00:00

commit f48e91e87e67b56bef63393d1a02c6e22c1d7078 upstream.

In commit dc3106690b20 ("powerpc: tm: Always use fp_state and vr_state
to store live registers"), a section of code was removed that copied
the current state to checkpointed state. That code should not have been
removed.

When an FP (Floating Point) unavailable is taken inside a transaction,
we need to abort the transaction. This is because at the time of the
tbegin, the FP state is bogus so the state stored in the checkpointed
registers is incorrect. To fix this, we treclaim (to get the
checkpointed GPRs) and then copy the thread_struct FP live state into
the checkpointed state. We then trecheckpoint so that the FP state is
correctly restored into the CPU.

The copying of the FP registers from live to checkpointed is what was
missing.

This simplifies the logic slightly from the original patch.
tm_reclaim_thread() will now always write the checkpointed FP
state. Either the checkpointed FP state will be written as part of
the actual treclaim (in tm.S), or it'll be a copy of the live
state. Which one we use is based on MSR[FP] from userspace.

Similarly for VMX.

Fixes: dc3106690b20 ("powerpc: tm: Always use fp_state and vr_state to store live registers")
Signed-off-by: Michael Neuling 
Reviewed-by: cyrilbur@gmail.com
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

powerpc/oops: Fix missing pr_cont()s in instruction dump

2016-11-12T09:12:51+00:00

Since the KERN_CONT changes, the current code in show_instructions()
prints out a whole bunch of unnecessary newlines. Change occurrences of
printk("\n") to pr_cont("\n"). While we're here, change all the other
cases of printk(KERN_CONT ...) to pr_cont() as well.

Signed-off-by: Andrew Donnellan 
Signed-off-by: Michael Ellerman

powerpc/oops: Fix missing pr_cont()s in show_regs()

2016-11-12T09:12:50+00:00

Fix up our oops output by converting continuation lines to use
pr_cont(). Some of these are dubious, eg. printing a continuation line
which starts with a newline, but seem to work OK for now. This whole
function needs a rewrite in the next release.

Signed-off-by: Michael Ellerman

powerpc/oops: Fix missing pr_cont()s in print_msr_bits() et. al.

2016-11-12T09:12:50+00:00

Since the KERN_CONT changes these are being horribly split across lines,
for example:

    MSR: 8000000000009033 <
    SF,EE
    ,ME,IR
    ,DR,RI
    ,LE>

So fix it by using pr_cont() where appropriate.

Signed-off-by: Michael Ellerman

powerpc/oops: Fix missing pr_cont()s in show_stack()

2016-11-12T09:12:49+00:00

Previously we got away with printing the stack trace in multiple pieces
and it usually looked right.  But since commit 4bcc595ccd80 ("printk:
reinstate KERN_CONT for printing continuation lines"), KERN_CONT is now
required when printing continuation lines. Use pr_cont() as appropriate.

Signed-off-by: Michael Ellerman

powerpc/process: Fix CONFIG_ALIVEC typo in restore_tm_state()

2016-10-27T10:52:59+00:00

It should be ALTIVEC, not ALIVEC.

Cyril explains: If a thread performs a transaction with altivec and then
gets preempted for whatever reason, this bug may cause the kernel to not
re-enable altivec when that thread runs again. This will result in an
altivec unavailable fault, when that fault happens inside a user
transaction the kernel has no choice but to enable altivec and doom the
transaction.

The result is that transactions using altivec may get aborted more often
than they should.

The difficulty in catching this with a selftest is my deliberate use of
the word may above. Optimisations to avoid FPU/altivec/VSX faults mean
that the kernel will always leave them on for 255 switches. This code
prevents the kernel turning it off if it got to the 256th switch (and
userspace was transactional).

Fixes: dc16b553c949 ("powerpc: Always restore FPU/VEC/VSX if hardware transactional memory in use")
Reviewed-by: Cyril Bur 
Signed-off-by: Valentin Rothberg 
Signed-off-by: Michael Ellerman

powerpc: tm: Enable transactional memory (TM) lazily for userspace

2016-10-04T09:33:17+00:00

Currently the MSR TM bit is always set if the hardware is TM capable.
This adds extra overhead as it means the TM SPRS (TFHAR, TEXASR and
TFAIR) must be swapped for each process regardless of if they use TM.

For processes that don't use TM the TM MSR bit can be turned off
allowing the kernel to avoid the expensive swap of the TM registers.

A TM unavailable exception will occur if a thread does use TM and the
kernel will enable MSR_TM and leave it so for some time afterwards.

Signed-off-by: Cyril Bur 
Signed-off-by: Michael Ellerman