tree 49366e977a2cc6fc995117aae5444a924a2c0e2d
parent 662d855c66c0a7400f9117b6ac02047942cd1d22
author Paul Burton <paul.burton@mips.com> 1529690145 -0700
committer Paul Burton <paul.burton@mips.com> 1530211734 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iIsEABYIADMWIQRgLjeFAZEXQzy86/s+p5+stXUA3QUCWzUtlhUccGF1bC5idXJ0
 b25AbWlwcy5jb20ACgkQPqefrLV1AN3N4AD9FBE3s//a8Rd5E21JddtvpCcBtlzY
 SF4MM6/66224pgkA/ibHJh35KIrriJgUDOxYT5/q0urp7cqhQshcYmog610M
 =fIOE
 -----END PGP SIGNATURE-----

MIPS: Call dump_stack() from show_regs()

The generic nmi_cpu_backtrace() function calls show_regs() when a struct
pt_regs is available, and dump_stack() otherwise. If we were to make use
of the generic nmi_cpu_backtrace() with MIPS' current implementation of
show_regs() this would mean that we see only register data with no
accompanying stack information, in contrast with our current
implementation which calls dump_stack() regardless of whether register
state is available.

In preparation for making use of the generic nmi_cpu_backtrace() to
implement arch_trigger_cpumask_backtrace(), have our implementation of
show_regs() call dump_stack() and drop the explicit dump_stack() call in
arch_dump_stack() which is invoked by arch_trigger_cpumask_backtrace().

This will allow the output we produce to remain the same after a later
patch switches to using nmi_cpu_backtrace(). It may mean that we produce
extra stack output in other uses of show_regs(), but this:

  1) Seems harmless.
  2) Is good for consistency between arch_trigger_cpumask_backtrace()
     and other users of show_regs().
  3) Matches the behaviour of the ARM & PowerPC architectures.

Marked for stable back to v4.9 as a prerequisite of the following patch
"MIPS: Call dump_stack() from show_regs()".

Signed-off-by: Paul Burton <paul.burton@mips.com>
Patchwork: https://patchwork.linux-mips.org/patch/19596/
Cc: James Hogan <jhogan@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Huacai Chen <chenhc@lemote.com>
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org # v4.9+