Skip to content
  1. May 13, 2016
  3. May 09, 2016
    • James Hogan's avatar
      MIPS: Avoid using unwind_stack() with usermode · 81a76d71
      James Hogan authored 
      

When showing backtraces in response to traps, for example crashes and
address errors (usually unaligned accesses) when they are set in debugfs
to be reported, unwind_stack will be used if the PC was in the kernel
text address range. However since EVA it is possible for user and kernel
address ranges to overlap, and even without EVA userland can still
trigger an address error by jumping to a KSeg0 address.

Adjust the check to also ensure that it was running in kernel mode. I
don't believe any harm can come of this problem, since unwind_stack() is
sufficiently defensive, however it is only meant for unwinding kernel
code, so to be correct it should use the raw backtracing instead.

Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
Reviewed-by: default avatarLeonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: <stable@vger.kernel.org> # 3.15+
Patchwork: https://patchwork.linux-mips.org/patch/11701/


Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
(cherry picked from commit d2941a975ac745c607dfb590e92bb30bc352dad9)
      81a76d71
  5. Apr 04, 2016
  7. Apr 03, 2016
  9. Mar 04, 2016
  11. Feb 02, 2016
    • Maciej W. Rozycki's avatar
      MIPS: traps.c: Correct microMIPS RDHWR emulation · 7aa70471
      Maciej W. Rozycki authored 
      

Fix the code to fetch and decode the whole 32-bit instruction.  This
only really matters with the `noulri' kernel parameter as all microMIPS
processors are supposed to have all the hardware registers we support.

Signed-off-by: default avatarMaciej W. Rozycki <macro@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12281/


Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      7aa70471
    • Maciej W. Rozycki's avatar
      MIPS: traps.c: Don't emulate RDHWR in the CpU #0 exception handler · 10f6d99f
      Maciej W. Rozycki authored 
      

In the regular MIPS instruction set RDHWR is encoded with the SPECIAL3
(011111) major opcode.  Therefore it cannot trigger the CpU (Coprocessor
Unusable) exception, and certainly not for coprocessor 0, as the opcode
does not overlap with any of the older ISA reservations, i.e. LWC0
(110000), SWC0 (111000), LDC0 (110100) or SDC0 (111100).  The closest
match might be SDC3 (111111), possibly causing a CpU #3 exception,
however our code does not handle it anyway.  A quick check with a MIPS I
and a MIPS III processor:

CPU0 revision is: 00000220 (R3000)
CPU0 revision is: 00000440 (R4400SC)

indeed indicates that the RI (Reserved Instruction) exception is
triggered.  It's only LL and SC that require emulation in the CpU #0
exception handler as they reuse the LWC0 and SWC0 opcodes respectively.

In the microMIPS instruction set RDHWR is mandatory and triggering the
RI exception is required on unimplemented or disabled register accesses.
Therefore emulating the microMIPS instruction in the CpU #0 exception
handler is not required either.

Signed-off-by: default avatarMaciej W. Rozycki <macro@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12280/


Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      10f6d99f
  13. Jan 24, 2016
  15. Nov 09, 2015
  17. Oct 26, 2015
  19. Sep 03, 2015
  21. Aug 26, 2015
  23. Aug 03, 2015
    • James Hogan's avatar
      MIPS: show_stack: Fix stack trace with EVA · 1e77863a
      James Hogan authored 
      

The show_stack() function deals exclusively with kernel contexts, but if
it gets called in user context with EVA enabled, show_stacktrace() will
attempt to access the stack using EVA accesses, which will either read
other user mapped data, or more likely cause an exception which will be
handled by __get_user().

This is easily reproduced using SysRq t to show all task states, which
results in the following stack dump output:

 Stack : (Bad stack address)

Fix by setting the current user access mode to kernel around the call to
show_stacktrace(). This causes __get_user() to use normal loads to read
the kernel stack.

Now we get the correct output, like this:

 Stack : 00000000 80168960 00000000 004a0000 00000000 00000000 8060016c 1f3abd0c
           1f172cd8 8056f09c 7ff1e450 8014fc3c 00000001 806dd0b0 0000001d 00000002
           1f17c6a0 1f17c804 1f17c6a0 8066f6e0 00000000 0000000a 00000000 00000000
           00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
           00000000 00000000 00000000 00000000 00000000 0110e800 1f3abd6c 1f17c6a0
           ...

Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: <stable@vger.kernel.org> # 3.15+
Patchwork: https://patchwork.linux-mips.org/patch/10778/


Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      1e77863a
    • James Hogan's avatar
      MIPS: do_mcheck: Fix kernel code dump with EVA · 55c723e1
      James Hogan authored 
      

If a machine check exception is raised in kernel mode, user context,
with EVA enabled, then the do_mcheck handler will attempt to read the
code around the EPC using EVA load instructions, i.e. as if the reads
were from user mode. This will either read random user data if the
process has anything mapped at the same address, or it will cause an
exception which is handled by __get_user, resulting in this output:

 Code: (Bad address in epc)

Fix by setting the current user access mode to kernel if the saved
register context indicates the exception was taken in kernel mode. This
causes __get_user to use normal loads to read the kernel code.

Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: <stable@vger.kernel.org> # 3.15+
Patchwork: https://patchwork.linux-mips.org/patch/10777/


Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      55c723e1
  25. Jul 09, 2015
  27. Jun 21, 2015
  29. May 12, 2015
  31. Apr 07, 2015
  33. Mar 31, 2015
    • James Hogan's avatar
      MIPS: Read CPU IRQ line that FDC to routed to · 8f7ff027
      James Hogan authored 
      

Read the CPU IRQ line reportedly used for the Fast Debug Channel (FDC)
interrupt from the IntCtl register and store it in cp0_fdc_irq where
platform implementations of the new weak platform function
get_c0_fdc_int() can refer to it.

[ralf@linux-mips.org: Fixed conflict.]

Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: James Hogan <james.hogan@imgtec.com>
Patchwork: https://patchwork.linux-mips.org/patch/9140/


Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      8f7ff027
    • James Hogan's avatar
      MIPS: Allow shared IRQ for timer & perf counter · 4a91d8fb
      James Hogan authored 
      

Before release 2 of the architecture there weren't separate interrupt
pending bits for the local CPU interrupts (timer & perf counter
overflow), so when they were connected to the same interrupt line the
timer handler had to call the performance counter handler before knowing
whether a timer interrupt was actually pending.

Now another CPU local interrupt, for the Fast Debug Channel (FDC), can
also be routed to an arbitrary interrupt line. It isn't scalable to keep
adding cross-calls between handlers for these cases of shared interrupt
lines, especially since the FDC could in theory share its interrupt line
with the performance counter, timer, or both.

Fortunately since release 2 of the architecture separate interrupt
pending bits do exist in the Cause register. This allows local
interrupts which share an interrupt line to have separate handlers using
IRQF_SHARED. Unfortunately they can't easily have their own irqchip as
there is no generic way to individually mask them.

Enable this sharing to happen by removing the special case for when the
perf count shares an IRQ with the timer. cp0_perfcount_irq and
cp0_compare_irq can then be set to the same value with shared interrupt
handlers registered for both of them.

Pre-R2 code should be unaffected. cp0_perfcount_irq will always be -1
and the timer handler will contnue to call into the perf counter
handler.

Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/9131/


Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      4a91d8fb
  35. Mar 27, 2015
    • James Hogan's avatar
      MIPS: Clear [MSA]FPE CSR.Cause after notify_die() · 64bedffe
      James Hogan authored 
      

When handling floating point exceptions (FPEs) and MSA FPEs the Cause
bits of the appropriate control and status register (FCSR for FPEs and
MSACSR for MSA FPEs) are read and cleared before enabling interrupts,
presumably so that it doesn't have to go through the pain of restoring
those bits if the process is pre-empted, since writing those bits would
cause another immediate exception while still in the kernel.

The bits aren't normally ever restored again, since userland never
expects to see them set.

However for virtualisation it is necessary for the kernel to be able to
restore these Cause bits, as the guest may have been interrupted in an
FP exception handler but before it could read the Cause bits. This can
be done by registering a die notifier, to get notified of the exception
when such a value is restored, and if the PC was at the instruction
which is used to restore the guest state, the handler can step over it
and continue execution. The Cause bits can then remain set without
causing further exceptions.

For this to work safely a few changes are made:
- __build_clear_fpe and __build_clear_msa_fpe no longer clear the Cause
  bits, and now return from exception level with interrupts disabled
  instead of enabled.
- do_fpe() now clears the Cause bits and enables interrupts after
  notify_die() is called, so that the notifier can chose to return from
  exception without this happening.
- do_msa_fpe() acts similarly, but now actually makes use of the second
  argument (msacsr) and calls notify_die() with the new DIE_MSAFP,
  allowing die notifiers to be informed of MSA FPEs too.

Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
Acked-by: default avatarRalf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Gleb Natapov <gleb@kernel.org>
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
      64bedffe
    • Paul Burton's avatar
      MIPS: Ensure FCSR cause bits are clear after invoking FPU emulator · ad70c13a
      Paul Burton authored 
      

When running the emulator to handle an instruction that raised an FP
unimplemented operation exception, the FCSR cause bits were being
cleared. This is done to ensure that the kernel does not take an FP
exception when later restoring FP context to registers. However, this
was not being done when the emulator is invoked in response to a
coprocessor unusable exception. This happens in 2 cases:

  - There is no FPU present in the system. In this case things were
    OK, since the FP context is never restored to hardware registers
    and thus no FP exception may be raised when restoring FCSR.

  - The FPU could not be configured to the mode required by the task.
    In this case it would be possible for the emulator to set cause
    bits which are later restored to hardware if the task migrates
    to a CPU whose associated FPU does support its mode requirements,
    or if the tasks FP mode requirements change.

Consistently clear the cause bits after invoking the emulator, by moving
the clearing to process_fpemu_return and ensuring this is always called
before the tasks FP context is restored. This will make it easier to
catch further paths invoking the emulator in future, as will be
introduced in further patches.

Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9165/


Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      ad70c13a
  37. Mar 05, 2015
  39. Feb 17, 2015