sh: stacktrace: Remove stacktrace_ops.stack()

The SH implementation never called stacktrace_ops.stack().
Presumably this was copied from the x86 implementation.

Hence remove the method, and all imp

sh: stacktrace: Remove stacktrace_ops.stack()

The SH implementation never called stacktrace_ops.stack().
Presumably this was copied from the x86 implementation.

Hence remove the method, and all implementations (most of them are
dummies).

Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Rich Felker <[email protected]>

show more ...

sh: dump_stack: Fix broken lines and ptrval in calltrace dumps

Rejoin the broken lines by dropping the log level parameters and using
pr_cont().
Use "%px" to print sensible addresses in call traces.

sh: dump_stack: Fix broken lines and ptrval in calltrace dumps

Rejoin the broken lines by dropping the log level parameters and using
pr_cont().
Use "%px" to print sensible addresses in call traces.

Signed-off-by: Geert Uytterhoeven <[email protected]>
Tested-by: Guenter Roeck <[email protected]>
Signed-off-by: Rich Felker <[email protected]>

show more ...

Revert "sh: remove needless printk()"

This reverts commit 8b92f34877225c8eb85e3ab7f1177fc248ba26d0.

"data" became the log level in commit 539e786cc37ee5cb ("sh: add loglvl
to show_trace()"), so we

Revert "sh: remove needless printk()"

This reverts commit 8b92f34877225c8eb85e3ab7f1177fc248ba26d0.

"data" became the log level in commit 539e786cc37ee5cb ("sh: add loglvl
to show_trace()"), so we do need to keep the printk() before the
continuation in print_trace_address().

Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Rich Felker <[email protected]>

show more ...

Revert "sh: add loglvl to printk_address()"

This reverts commit 2deebe4d56d638269a4a728086d64de5734b460a.

printk_address() is always used as a continuation of the previous
logging, hence it should

Revert "sh: add loglvl to printk_address()"

This reverts commit 2deebe4d56d638269a4a728086d64de5734b460a.

printk_address() is always used as a continuation of the previous
logging, hence it should not include a log level.

Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Rich Felker <[email protected]>

show more ...

kernel: rename show_stack_loglvl() => show_stack()

Now the last users of show_stack() got converted to use an explicit log
level, show_stack_loglvl() can drop it's redundant suffix and become once
a

kernel: rename show_stack_loglvl() => show_stack()

Now the last users of show_stack() got converted to use an explicit log
level, show_stack_loglvl() can drop it's redundant suffix and become once
again well known show_stack().

Signed-off-by: Dmitry Safonov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

sh: add show_stack_loglvl()

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the s

sh: add show_stack_loglvl()

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on a platform or
user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages. And in
result it not only may print unwanted messages from other CPUs, but also
omit printing at all in the unlucky case where the printk() was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems an easier
approach than introducing more printk buffers. Also, it will consolidate
printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

[1]: https://lore.kernel.org/lkml/[email protected]/T/#u

Signed-off-by: Dmitry Safonov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

sh: add loglvl to show_trace()

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than th

sh: add loglvl to show_trace()

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on a platform or
user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages. And in
result it not only may print unwanted messages from other CPUs, but also
omit printing at all in the unlucky case where the printk() was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems an easier
approach than introducing more printk buffers. Also, it will consolidate
printings with headers.

Add log level parameter to show_trace() as a preparation to introduce
show_stack_loglvl().

[1]: https://lore.kernel.org/lkml/[email protected]/T/#u

Signed-off-by: Dmitry Safonov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Cc: Rich Felker <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

sh: add loglvl to printk_address()

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher tha

sh: add loglvl to printk_address()

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on a platform or
user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages. And in
result it not only may print unwanted messages from other CPUs, but also
omit printing at all in the unlucky case where the printk() was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems an easier
approach than introducing more printk buffers. Also, it will consolidate
printings with headers.

Add log level argument to printk_address() as a preparation to introduce
show_stack_loglvl().

As a good side-effect show_fault_oops() now prints the address with
KERN_EMREG as the rest of output, making sure there won't be situation
where "PC: " is printed without actual address.

[1]: https://lore.kernel.org/lkml/[email protected]/T/#u

Signed-off-by: Dmitry Safonov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Cc: Rich Felker <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

sh: remove needless printk()

Currently `data' is always an empty line "". No need for additional
printk() call.

Signed-off-by: Dmitry Safonov <[email protected]>
Signed-off-by: Andrew Morton <akpm@l

sh: remove needless printk()

Currently `data' is always an empty line "". No need for additional
printk() call.

Signed-off-by: Dmitry Safonov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

sh: add loglvl to dump_mem()

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the

sh: add loglvl to dump_mem()

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on a platform or
user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages. And in
result it not only may print unwanted messages from other CPUs, but also
omit printing at all in the unlucky case where the printk() was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems an easier
approach than introducing more printk buffers. Also, it will consolidate
printings with headers.

Add log level argument to dump_mem() as a preparation to introduce
show_stack_loglvl().

[1]: https://lore.kernel.org/lkml/[email protected]/T/#u

Signed-off-by: Dmitry Safonov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

sh: kernel: convert to SPDX identifiers

Update license to use SPDX-License-Identifier instead of verbose license
text.

Link: http://lkml.kernel.org/r/[email protected]

sh: kernel: convert to SPDX identifiers

Update license to use SPDX-License-Identifier instead of verbose license
text.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Kuninori Morimoto <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

sh: ftrace: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack

The structure of the ret_stack array on the task struct is going to
change, and accessing it directly via the curr_ret_stack in

sh: ftrace: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack

The structure of the ret_stack array on the task struct is going to
change, and accessing it directly via the curr_ret_stack index will no
longer give the ret_stack entry that holds the return address. To access
that, architectures must now use ftrace_graph_get_ret_stack() to get the
associated ret_stack that matches the saved return address.

Cc: [email protected]
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>

show more ...

sched/headers: Prepare for new header dependencies before moving code to <linux/sched/task_stack.h>

We are going to split <linux/sched/task_stack.h> out of <linux/sched.h>, which
will have to be pic

sched/headers: Prepare for new header dependencies before moving code to <linux/sched/task_stack.h>

We are going to split <linux/sched/task_stack.h> out of <linux/sched.h>, which
will have to be picked up from other headers and a couple of .c files.

Create a trivial placeholder <linux/sched/task_stack.h> file that just
maps to <linux/sched.h> to make this patch obviously correct and
bisectable.

Include the new header in the files that are going to need it.

Acked-by: Linus Torvalds <[email protected]>
Cc: Mike Galbraith <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Signed-off-by: Ingo Molnar <[email protected]>

show more ...

sched/headers: Prepare for new header dependencies before moving code to <linux/sched/debug.h>

We are going to split <linux/sched/debug.h> out of <linux/sched.h>, which
will have to be picked up fro

sched/headers: Prepare for new header dependencies before moving code to <linux/sched/debug.h>

We are going to split <linux/sched/debug.h> out of <linux/sched.h>, which
will have to be picked up from other headers and a couple of .c files.

Create a trivial placeholder <linux/sched/debug.h> file that just
maps to <linux/sched.h> to make this patch obviously correct and
bisectable.

Include the new header in the files that are going to need it.

Acked-by: Linus Torvalds <[email protected]>
Cc: Mike Galbraith <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Signed-off-by: Ingo Molnar <[email protected]>

show more ...

sh: fix format string bug in stack tracer

Kees reported the following error:

arch/sh/kernel/dumpstack.c: In function 'print_trace_address':
arch/sh/kernel/dumpstack.c:118:2: error: format not

sh: fix format string bug in stack tracer

Kees reported the following error:

arch/sh/kernel/dumpstack.c: In function 'print_trace_address':
arch/sh/kernel/dumpstack.c:118:2: error: format not a string literal and no format arguments [-Werror=format-security]

Use the "%s" format so that it's impossible to interpret 'data' as a
format string.

Signed-off-by: Matt Fleming <[email protected]>
Reported-by: Kees Cook <[email protected]>
Acked-by: Kees Cook <[email protected]>
Cc: Paul Mundt <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

dump_stack: consolidate dump_stack() implementations and unify their behaviors

Both dump_stack() and show_stack() are currently implemented by each
architecture. show_stack(NULL, NULL) dumps the ba

dump_stack: consolidate dump_stack() implementations and unify their behaviors

Both dump_stack() and show_stack() are currently implemented by each
architecture. show_stack(NULL, NULL) dumps the backtrace for the
current task as does dump_stack(). On some archs, dump_stack() prints
extra information - pid, utsname and so on - in addition to the
backtrace while the two are identical on other archs.

The usages in arch-independent code of the two functions indicate
show_stack(NULL, NULL) should print out bare backtrace while
dump_stack() is used for debugging purposes when something went wrong,
so it does make sense to print additional information on the task which
triggered dump_stack().

There's no reason to require archs to implement two separate but mostly
identical functions. It leads to unnecessary subtle information.

This patch expands the dummy fallback dump_stack() implementation in
lib/dump_stack.c such that it prints out debug information (taken from
x86) and invokes show_stack(NULL, NULL) and drops arch-specific
dump_stack() implementations in all archs except blackfin. Blackfin's
dump_stack() does something wonky that I don't understand.

Debug information can be printed separately by calling
dump_stack_print_info() so that arch-specific dump_stack()
implementation can still emit the same debug information. This is used
in blackfin.

This patch brings the following behavior changes.

* On some archs, an extra level in backtrace for show_stack() could be
printed. This is because the top frame was determined in
dump_stack() on those archs while generic dump_stack() can't do that
reliably. It can be compensated by inlining dump_stack() but not
sure whether that'd be necessary.

* Most archs didn't use to print debug info on dump_stack(). They do
now.

An example WARN dump follows.

WARNING: at kernel/workqueue.c:4841 init_workqueues+0x35/0x505()
Hardware name: empty
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.9.0-rc1-work+ #9
0000000000000009 ffff88007c861e08 ffffffff81c614dc ffff88007c861e48
ffffffff8108f50f ffffffff82228240 0000000000000040 ffffffff8234a03c
0000000000000000 0000000000000000 0000000000000000 ffff88007c861e58
Call Trace:
[<ffffffff81c614dc>] dump_stack+0x19/0x1b
[<ffffffff8108f50f>] warn_slowpath_common+0x7f/0xc0
[<ffffffff8108f56a>] warn_slowpath_null+0x1a/0x20
[<ffffffff8234a071>] init_workqueues+0x35/0x505
...

v2: CPU number added to the generic debug info as requested by s390
folks and dropped the s390 specific dump_stack(). This loses %ksp
from the debug message which the maintainers think isn't important
enough to keep the s390-specific dump_stack() implementation.

dump_stack_print_info() is moved to kernel/printk.c from
lib/dump_stack.c. Because linkage is per objecct file,
dump_stack_print_info() living in the same lib file as generic
dump_stack() means that archs which implement custom dump_stack()
- at this point, only blackfin - can't use dump_stack_print_info()
as that will bring in the generic version of dump_stack() too. v1
The v1 patch broke build on blackfin due to this issue. The build
breakage was reported by Fengguang Wu.

Signed-off-by: Tejun Heo <[email protected]>
Acked-by: David S. Miller <[email protected]>
Acked-by: Vineet Gupta <[email protected]>
Acked-by: Jesper Nilsson <[email protected]>
Acked-by: Vineet Gupta <[email protected]>
Acked-by: Martin Schwidefsky <[email protected]> [s390 bits]
Cc: Heiko Carstens <[email protected]>
Cc: Mike Frysinger <[email protected]>
Cc: Fengguang Wu <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Acked-by: Richard Kuo <[email protected]> [hexagon bits]
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

sh64: Convert to unwinder API.

This switches over to use the sh unwinder API which brings it all in line
with the general sh routines (which we shuffle around at the same time),
and lets us kill off

sh64: Convert to unwinder API.

This switches over to use the sh unwinder API which brings it all in line
with the general sh routines (which we shuffle around at the same time),
and lets us kill off more sh64-specific cruft.

Signed-off-by: Paul Mundt <[email protected]>

show more ...

sh: remove warning and warning_symbol from struct stacktrace_ops

Both warning and warning_symbol are nowhere used.
Let's get rid of them.

Signed-off-by: Richard Weinberger <[email protected]>
Signed-o

sh: remove warning and warning_symbol from struct stacktrace_ops

Both warning and warning_symbol are nowhere used.
Let's get rid of them.

Signed-off-by: Richard Weinberger <[email protected]>
Signed-off-by: Paul Mundt <[email protected]>

show more ...

sh: flag the default unwinder as reliable.

This flags the default unwinder as reliable, as it tends to be reliable
enough for the purposes of the stacktrace buffer. We leave the unreliable
cases for

sh: flag the default unwinder as reliable.

This flags the default unwinder as reliable, as it tends to be reliable
enough for the purposes of the stacktrace buffer. We leave the unreliable
cases for the unwind methods that we know to be completely broken.

Signed-off-by: Paul Mundt <[email protected]>

show more ...

sh: Use the new stack unwinder API

Instead of implementing our own stack unwinder via dump_trace() we
should use the new stack unwinder API because it is more modular. This
change allows us to decou

sh: Use the new stack unwinder API

Instead of implementing our own stack unwinder via dump_trace() we
should use the new stack unwinder API because it is more modular. This
change allows us to decouple the interface for generating stacktraces
from the implementation of a stack unwinder.

Signed-off-by: Matt Fleming <[email protected]>
Signed-off-by: Paul Mundt <[email protected]>

show more ...

sh: Use the generalized stacktrace ops

Copy the stacktrace ops code from x86 and provide a central function for
use by functions that need to dump a callstack.

Signed-off-by: Matt Fleming <matt@con

sh: Use the generalized stacktrace ops

Copy the stacktrace ops code from x86 and provide a central function for
use by functions that need to dump a callstack.

Signed-off-by: Matt Fleming <[email protected]>
Signed-off-by: Paul Mundt <[email protected]>

show more ...