linux-stable.git/arch/mips/kernel/process.c, branch v3.18.136

kthread: fix boot hang (regression) on MIPS/OpenRISC

2018-09-26T06:33:53+00:00

commit b0f5a8f32e8bbdaae1abb8abe2d3cbafaba57e08 upstream.

This fixes a regression in commit 4d6501dce079 where I didn't notice
that MIPS and OpenRISC were reinitialising p->{set,clear}_child_tid to
NULL after our initialisation in copy_process().

We can simply get rid of the arch-specific initialisation here since it
is now always done in copy_process() before hitting copy_thread{,_tls}().

Review notes:

 - As far as I can tell, copy_process() is the only user of
   copy_thread_tls(), which is the only caller of copy_thread() for
   architectures that don't implement copy_thread_tls().

 - After this patch, there is no arch-specific code touching
   p->set_child_tid or p->clear_child_tid whatsoever.

 - It may look like MIPS/OpenRISC wanted to always have these fields be
   NULL, but that's not true, as copy_process() would unconditionally
   set them again _after_ calling copy_thread_tls() before commit
   4d6501dce079.

Fixes: 4d6501dce079c1eb6bf0b1d8f528a5e81770109e ("kthread: Fix use-after-free if kthread fork fails")
Reported-by: Guenter Roeck 
Tested-by: Guenter Roeck  # MIPS only
Acked-by: Stafford Horne 
Acked-by: Oleg Nesterov 
Cc: Ralf Baechle 
Cc: linux-mips@linux-mips.org
Cc: Jonas Bonn 
Cc: Stefan Kristiansson 
Cc: openrisc@lists.librecores.org
Cc: Jamie Iles 
Cc: Thomas Gleixner 
Signed-off-by: Vegard Nossum 
Signed-off-by: Linus Torvalds 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

MIPS: Don't unwind to user mode with EVA

2016-06-03T15:30:37+00:00

[ Upstream commit a816b306c62195b7c43c92cb13330821a96bdc27 ]

When unwinding through IRQs and exceptions, the unwinding only continues
if the PC is a kernel text address, however since EVA it is possible for
user and kernel address ranges to overlap, potentially allowing
unwinding to continue to user mode if the user PC happens to be in the
kernel text address range.

Adjust the check to also ensure that the register state from before the
exception is actually running in kernel mode, i.e. !user_mode(regs).

I don't believe any harm can come of this problem, since the PC is only
output, the stack pointer is checked to ensure it resides within the
task's stack page before it is dereferenced in search of the return
address, and the return address register is similarly only output (if
the PC is in a leaf function or the beginning of a non-leaf function).

However unwind_stack() is only meant for unwinding kernel code, so to be
correct the unwind should stop there.

Signed-off-by: James Hogan 
Reviewed-by: Leonid Yegoshin 
Cc: linux-mips@linux-mips.org
Cc:  # 3.15+
Patchwork: https://patchwork.linux-mips.org/patch/11700/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin

MIPS: consistently clear MSA flags when starting & copying threads

2014-08-01T22:06:45+00:00

The TIF_MSA_CTX_LIVE flag (indicating that a task has MSA context which
needs to be preserved) was being cleared in start_thread, but the
TIF_USEDMSA flag (indicating that a task has used MSA in this timeslice)
was not. In copy_thread neither flag was cleared, but both need to be.
Without clearing these flags the kernel will proceed to attempt to save
MSA context when the task is context switched out, and if the task had
not used MSA in the meantime then it will fail because MSA or the FPU
are disabled. The end result is typically:

  do_cpu invoked from kernel context![#1]:
  CPU: 0 PID: 99 Comm: sh Not tainted 3.16.0-rc4-00025-g6dc9476-dirty #88
  task: 8f23dc60 ti: 8f1d8000 task.ti: 8f1d8000
  ...
  Call Trace:
  [<8010edbc>] resume+0x5c/0x280
  [<80481e0c>] __schedule+0x370/0x800
  [<80104838>] work_resched+0x8/0x2c

Fix by consistently clearing both flags in both functions.

Signed-off-by: Paul Burton 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7309/
Signed-off-by: Ralf Baechle

MIPS: Remove asm/user.h

2014-08-01T22:06:37+00:00

The struct user definition in this file is not used anywhere (the ELF
core dumper does not use that format). Therefore, remove the header and
instead enable the asm-generic user.h which is an empty header to
satisfy a few generic headers which still try to include user.h.

Signed-off-by: Alex Smith 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7459/
Signed-off-by: Ralf Baechle

MIPS: Remove old core dump functions

2014-08-01T22:06:37+00:00

Since the core dumper now uses regsets, the old core dump functions are
now unused. Remove them.

Signed-off-by: Alex Smith 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7456/
Signed-off-by: Ralf Baechle

MIPS: MT: Remove SMTC support

2014-05-23T22:07:01+00:00

Nobody is maintaining SMTC anymore and there also seems to be no userbase.
Which is a pity - the SMTC technology primarily developed by Kevin D.
Kissell  is an ingenious demonstration for the MT
ASE's power and elegance.

Based on Markos Chandras  patch
https://patchwork.linux-mips.org/patch/6719/ which while very similar did
no longer apply cleanly when I tried to merge it plus some additional
post-SMTC cleanup - SMTC was a feature as tricky to remove as it was to
merge once upon a time.

Signed-off-by: Ralf Baechle

MIPS: Basic MSA context switching support

2014-03-26T22:09:10+00:00

This patch adds support for context switching the MSA vector registers.
These 128 bit vector registers are aliased with the FP registers - an
FP register accesses the least significant bits of the vector register
with which it is aliased (ie. the register with the same index). Due to
both this & the requirement that the scalar FPU must be 64-bit (FR=1) if
enabled at the same time as MSA the kernel will enable MSA & scalar FP
at the same time for tasks which use MSA. If we restore the MSA vector
context then we might as well enable the scalar FPU since the reason it
was left disabled was to allow for lazy FP context restoring - but we
just restored the FP context as it's a subset of the vector context. If
we restore the FP context and have previously used MSA then we have to
restore the whole vector context anyway (see comment in
enable_restore_fp_context for details) so similarly we might as well
enable MSA.

Thus if a task does not use MSA then it will continue to behave as
without this patch - the scalar FP context will be saved & restored as
usual. But if a task executes an MSA instruction then it will save &
restore the vector context forever more.

Signed-off-by: Paul Burton 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6431/
Signed-off-by: Ralf Baechle

MIPS: Don't assume 64-bit FP registers for dump_{,task_}fpu

2014-03-26T22:09:10+00:00

This code assumed that saved FP registers are 64 bits wide, an
assumption which will no longer be true once MSA is introduced. This
patch modifies the code to copy the lower 64 bits of each register in
turn, which is safe for any FP register width >= 64 bits.

Signed-off-by: Paul Burton 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6425/
Signed-off-by: Ralf Baechle

MIPS: replace open-coded init_dsp

2014-01-24T21:39:45+00:00

There is already an init_dsp function which checks cpu_has_dsp & calls
__init_dsp if it does. Make use of it instead of duplicating the same
code.

Signed-off-by: Paul Burton 
Reviewed-by: Qais Yousef 
Signed-off-by: John Crispin 
Patchwork: http://patchwork.linux-mips.org/patch/6148/

MIPS: Support for 64-bit FP with O32 binaries

2014-01-13T22:40:56+00:00

CPUs implementing MIPS32 R2 may include a 64-bit FPU, just as MIPS64 CPUs
do. In order to preserve backwards compatibility a 64-bit FPU will act
like a 32-bit FPU (by accessing doubles from the least significant 32
bits of an even-odd pair of FP registers) when the Status.FR bit is
zero, again just like a mips64 CPU. The standard O32 ABI is defined
expecting a 32-bit FPU, however recent toolchains support use of a
64-bit FPU from an O32 MIPS32 executable. When an ELF executable is
built to use a 64-bit FPU a new flag (EF_MIPS_FP64) is set in the ELF
header.

With this patch the kernel will check the EF_MIPS_FP64 flag when
executing an O32 binary, and set Status.FR accordingly. The addition
of O32 64-bit FP support lessens the opportunity for optimisation in
the FPU emulator, so a CONFIG_MIPS_O32_FP64_SUPPORT Kconfig option is
introduced to allow this support to be disabled for those that don't
require it.

Inspired by an earlier patch by Leonid Yegoshin, but implemented more
cleanly & correctly.

Signed-off-by: Paul Burton 
Cc: linux-mips@linux-mips.org
Cc: Paul Burton 
Patchwork: https://patchwork.linux-mips.org/patch/6154/
Signed-off-by: Ralf Baechle