Add SPDX license identifiers to all files which:
- Have no license information of any form
- Have EXPORT_.*_SYMBOL_GPL inside which was used in the
initial scan/conversion to ignore the file
These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:
GPL-2.0-only
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Alexander Potapenko <glider@google.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
Link: https://lkml.kernel.org/r/20190410103643.843075256@linutronix.de
Avoid adding kprobes to any of the kernel entry/exit or startup
assembly code, or code in the identity-mapped region. This code does
not conform to the standard C conventions, which means that the
expectations of the kprobes code is not forfilled.
Placing kprobes at some of these locations results in the kernel trying
to return to userspace addresses while retaining the CPU in kernel mode.
Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
The kernel watchdog is a great debugging tool for finding tasks that
consume a disproportionate amount of CPU time in contiguous chunks. One
can imagine building a similar watchdog for arbitrary driver threads
using save_stack_trace_tsk() and print_stack_trace(). However, this is
not viable for dynamically loaded driver modules on ARM platforms
because save_stack_trace_tsk() is not exported for those architectures.
Export save_stack_trace_tsk() for the ARM architecture to align with
x86 and support various debugging use cases such as arbitrary driver
thread watchdog timers.
Signed-off-by: Dustin Brown <dustinb@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
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 <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Use the global current_stack_pointer to get the value of the stack pointer.
This change supports being able to compile the kernel with both gcc and clang.
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When configure kprobe events of ftrace with "stacktrace" option enabled
in arm, there is no stacktrace was recorded after the kprobe event was
triggered. The root cause is no save_stack_trace_regs() function implemented.
Implement the save_stack_trace_regs() function in arm, then ftrace will
call this architecture-related function to record the stacktrace into
ring buffer.
After this fix, stacktrace can be recorded, for example:
# mount -t debugfs nodev /sys/kernel/debug
# echo "p:netrx net_rx_action" >> /sys/kernel/debug/tracing/kprobe_events
# echo 1 > /sys/kernel/debug/tracing/events/kprobes/netrx/enable
# echo 1 > /sys/kernel/debug/tracing/options/stacktrace
# echo 1 > /sys/kernel/debug/tracing/tracing_on
# ping 127.0.0.1 -c 1
# echo 0 > /sys/kernel/debug/tracing/tracing_on
# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 12/12 #P:1
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
<------ missing some entries ---------------->
ping-1200 [000] dNs1 667.603250: netrx: (net_rx_action+0x0/0x1f8)
ping-1200 [000] dNs1 667.604738: <stack trace>
=> net_rx_action
=> do_softirq
=> local_bh_enable
=> ip_finish_output
=> ip_output
=> ip_local_out
=> ip_send_skb
=> ip_push_pending_frames
=> raw_sendmsg
=> inet_sendmsg
=> sock_sendmsg
=> SyS_sendto
=> ret_fast_syscall
Signed-off-by: Lin Yongting <linyongting@gmail.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When we unwind through an exception stack, include the saved PC value
into the stack trace: this fills in an otherwise missed functions from
the trace (as indicated below):
[<c03f4424>] fec_enet_interrupt+0xa0/0xe8
[<c0066c0c>] handle_irq_event_percpu+0x68/0x228
[<c0066e18>] handle_irq_event+0x4c/0x6c
[<c006a024>] handle_fasteoi_irq+0xac/0x198
[<c00664b0>] generic_handle_irq+0x4c/0x60
[<c000f014>] handle_IRQ+0x40/0x98
[<c0008554>] gic_handle_irq+0x30/0x64
[<c0012900>] __irq_svc+0x40/0x50
[<c0029030>] __do_softirq+0xe0/0x2fc <====
[<c0029500>] irq_exit+0xb0/0x100
[<c000f018>] handle_IRQ+0x44/0x98
[<c0008554>] gic_handle_irq+0x30/0x64
[<c0012900>] __irq_svc+0x40/0x50
[<c000f34c>] arch_cpu_idle+0x30/0x38 <====
[<c005e1e4>] cpu_startup_entry+0xac/0x214
[<c066297c>] rest_init+0x68/0x80
[<c08ccb10>] start_kernel+0x2fc/0x358
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
While debugging the FEC ethernet driver using stacktrace, it was noticed
that the stacktraces always begin as follows:
[<c00117b4>] save_stack_trace_tsk+0x0/0x98
[<c0011870>] save_stack_trace+0x24/0x28
...
This is because the stack trace code includes the stack frames for itself.
This is incorrect behaviour, and also leads to "skip" doing the wrong
thing (which is the number of stack frames to avoid recording.)
Perversely, it does the right thing when passed a non-current thread. Fix
this by ensuring that we have a known constant number of frames above the
main stack trace function, and always skip these.
Cc: <stable@vger.kernel.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch fixes corner case when (fp + 4) overflows unsigned long,
for example: fp = 0xFFFFFFFF -> fp + 4 == 3.
Cc: <stable@vger.kernel.org>
Signed-off-by: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Many of the core ARM kernel files are not modules, but just
including module.h for exporting symbols. Now these files can
use the lighter footprint export.h for this role.
There are probably lots more, but ARM files of mach-* and plat-*
don't get coverage via a simple yesconfig build. They will have
to be cleaned up and tested via using their respective configs.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Rabin Vincent reports:
| On SMP, this BUG() in save_stack_trace_tsk() can be easily triggered
| from user space by reading /proc/$PID/stack, where $PID is any pid but
| the current process:
|
| if (tsk != current) {
| #ifdef CONFIG_SMP
| /*
| * What guarantees do we have here that 'tsk'
| * is not running on another CPU?
| */
| BUG();
| #else
Fix this by replacing the BUG() with an entry to terminate the stack
trace, returning an empty trace - I'd rather not expose the dwarf
unwinder to a volatile stack of a running thread.
Reported-by: Rabin Vincent <rabin@rab.in>
Tested-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When unwinding stack frames we must take care not to unwind
areas of memory that lie outside of the known extent of the stack.
This patch fixes an incorrect calculation of the stack base where
THREAD_SIZE is added to the stack pointer after it has already
been aligned to this value. Since the ALIGN macro performs this
addition internally, we end up overshooting the base by 8k.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
As __builtin_return_address(n) doesn't work for ARM with n > 0, the
kernel needs its own implementation.
This fixes many warnings saying:
warning: unsupported argument to '__builtin_return_address'
The new methods and walk_stackframe must not be instrumented because
CALLER_ADDRESSx is used in the various tracers and tracing the tracer is
a bad idea.
What's currently missing is an implementation using unwind tables. This
is not fatal though, it's just that the tracers don't get enough
information to be really useful.
Note that if both ARM_UNWIND and FRAME_POINTER are enabled,
walk_stackframe uses unwind information. So in this case the same
implementation is used as when FRAME_POINTER is disabled.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch changes the walk_stacktrace and its callers for easier
integration of stack unwinding. The arch/arm/kernel/stacktrace.h file is
also moved to arch/arm/include/asm/stacktrace.h.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Andrew Morton reported this against linux-next:
ERROR: ".save_stack_trace" [tests/backtracetest.ko] undefined!
Reported-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Available for !SMP only at the moment.
From Russell:
|Basically, if a thread is running on a CPU, thread_saved_fp() is invalid.
|So, the question is: what guarantees do we have here that 'tsk' is not
|running on another CPU?
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Fix an oops in the stacktrace code, caused by improper range checking.
We subtract 12 off 'fp' before testing to see if it's below the low
bound. However, if 'fp' were zero before, it becomes a very large
positive number, causing this test to succeed where it should fail.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ab1b6f03a1 said
- remove the unused task argument to save_stack_trace, it's always current
then broke arm:
arch/arm/kernel/stacktrace.c:56: error: conflicting types for 'save_stack_trace'
include/linux/stacktrace.h:11: error: previous declaration of 'save_stack_trace' was here
arch/arm/kernel/stacktrace.c:56: error: conflicting types for 'save_stack_trace'
include/linux/stacktrace.h:11: error: previous declaration of 'save_stack_trace' was here
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add support for stacktrace. Use the new stacktrace code with
oprofile instead of it's version; there's no point having
multiple versions of stacktracing in the kernel.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
