linux.git/arch/arm64/kernel/traps.c, branch v4.4

arm64: Synchronise dump_backtrace() with perf callchain

2015-10-19T17:51:52+00:00

Unlike perf callchain relying on walk_stackframe(), dump_backtrace()
has its own backtrace logic. A major difference between them is the
moment a symbol is recorded. Perf writes down a symbol *before*
calling unwind_frame(), but dump_backtrace() prints it out *after*
unwind_frame(). As a result, the last valid symbol cannot be hooked
in case of dump_backtrace(). This patch addresses the issue as
synchronising dump_backtrace() with perf callchain.

A simple test and its results are as follows:

- crash trigger

 $ sudo echo c > /proc/sysrq-trigger

- current status

 Call trace:
 [] sysrq_handle_crash+0x24/0x30
 [] __handle_sysrq+0x128/0x19c
 [] write_sysrq_trigger+0x60/0x74
 [] proc_reg_write+0x84/0xc0
 [] __vfs_write+0x44/0x104
 [] vfs_write+0x98/0x1a8
 [] SyS_write+0x50/0xb0

- with this change

 Call trace:
 [] sysrq_handle_crash+0x24/0x30
 [] __handle_sysrq+0x128/0x19c
 [] write_sysrq_trigger+0x60/0x74
 [] proc_reg_write+0x84/0xc0
 [] __vfs_write+0x44/0x104
 [] vfs_write+0x98/0x1a8
 [] SyS_write+0x50/0xb0
 [] el0_svc_naked+0x20/0x28

Note that this patch does not cover a case where MMU is disabled. The
last stack frame of swapper, for example, has PC in a form of physical
address. Unfortunately, a simple conversion using phys_to_virt() cannot
cover all scenarios since PC is retrieved from LR - 4, not LR. It is
a big tradeoff to change both head.S and unwind_frame() for only a few
of symbols in *.S. Thus, this hunk does not take care of the case.

Cc: AKASHI Takahiro 
Cc: James Morse 
Cc: Mark Rutland 
Signed-off-by: Jungseok Lee 
Signed-off-by: Catalin Marinas

arm64/BUG: Show explicit backtrace for WARNs

2015-07-27T10:08:42+00:00

The generic slowpath WARN implementation prints a backtrace, but
the report_bug() based implementation does not, opting to print the
registers instead which is generally not as useful.

Ideally, report_bug() should be fixed to make the behaviour more
consistent, but in the meantime this patch generates a backtrace
directly from the arm64 backend instead so that this functionality
is not lost with the migration to report_bug().

As a side-effect, the backtrace will be outside the oops end
marker, but that's hard to avoid without modifying generic code.

This patch can go away if report_bug() grows the ability in the
future to generate a backtrace directly or call an arch hook at the
appropriate time.

Signed-off-by: Dave Martin 
Acked-by: Catalin Marinas 
Signed-off-by: Will Deacon

arm64/BUG: Use BRK instruction for generic BUG traps

2015-07-27T10:08:42+00:00

Currently, the minimal default BUG() implementation from asm-
generic is used for arm64.

This patch uses the BRK software breakpoint instruction to generate
a trap instead, similarly to most other arches, with the generic
BUG code generating the dmesg boilerplate.

This allows bug metadata to be moved to a separate table and
reduces the amount of inline code at BUG and WARN sites.  This also
avoids clobbering any registers before they can be dumped.

To mitigate the size of the bug table further, this patch makes
use of the existing infrastructure for encoding addresses within
the bug table as 32-bit offsets instead of absolute pointers.
(Note that this limits the kernel size to 2GB.)

Traps are registered at arch_initcall time for aarch64, but BUG
has minimal real dependencies and it is desirable to be able to
generate bug splats as early as possible.  This patch redirects
all debug exceptions caused by BRK directly to bug_handler() until
the full debug exception support has been initialised.

Signed-off-by: Dave Martin 
Reviewed-by: Catalin Marinas 
Signed-off-by: Will Deacon

arm64: force CONFIG_SMP=y and remove redundant #ifdefs

2015-07-27T10:08:40+00:00

Nobody seems to be producing !SMP systems anymore, so this is just
becoming a source of kernel bugs, particularly if people want to use
coherent DMA with non-shared pages.

This patch forces CONFIG_SMP=y for arm64, removing a modest amount of
code in the process.

Signed-off-by: Will Deacon

arm64: modify the dump mem for 64 bit addresses

2015-07-27T10:08:38+00:00

On 64bit kernel, the dump_mem gives 32 bit addresses
on the stack dump. This gives unorganized information regarding
the 64bit values on the stack. Hence, modified to get a complete 64bit memory
dump.

With patch:
[   93.534801] Process insmod (pid: 1587, stack limit = 0xffffffc976be4058)
[   93.541441] Stack: (0xffffffc976be7cf0 to 0xffffffc976be8000)
[   93.547136] 7ce0:                                   ffffffc976be7d00 ffffffc00008163c
[   93.554898] 7d00: ffffffc976be7d40 ffffffc0000f8a44 ffffffc00098ef38 ffffffbffc000088
[   93.562659] 7d20: ffffffc00098ef50 ffffffbffc0000c0 0000000000000001 ffffffbffc000070
[   93.570419] 7d40: ffffffc976be7e40 ffffffc0000f935c 0000000000000000 000000002b424090
[   93.578179] 7d60: 000000002b424010 0000007facc555f4 0000000080000000 0000000000000015
[   93.585937] 7d80: 0000000000000116 0000000000000069 ffffffc00097b000 ffffffc976be4000
[   93.593694] 7da0: 0000000000000064 0000000000000072 000000000000006e 000000000000003f
[   93.601453] 7dc0: 000000000000feff 000000000000fff1 ffffffbffc002028 0000000000000124
[   93.609211] 7de0: ffffffc976be7e10 0000000000000001 ffffff8000000000 ffffffbbffff0000
[   93.616969] 7e00: ffffffc976be7e60 0000000000000000 0000000000000000 0000000000000000
[   93.624726] 7e20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[   93.632484] 7e40: 0000007fcc474550 ffffffc0000841ec 000000002b424010 0000007facda0710
[   93.640241] 7e60: ffffffffffffffff ffffffc0000be6dc ffffff80007d2000 000000000001c010
[   93.647999] 7e80: ffffff80007e0ae0 ffffff80007e09d0 ffffff80007edf70 0000000000000288
[   93.655757] 7ea0: 00000000000002e8 0000000000000000 0000000000000000 0000001c0000001b
[   93.663514] 7ec0: 0000000000000009 0000000000000007 000000002b424090 000000000001c010
[   93.671272] 7ee0: 000000002b424010 0000007faccd3a48 0000000000000000 0000000000000000
[   93.679030] 7f00: 0000007fcc4743f8 0000007fcc4743f8 0000000000000069 0000000000000003
[   93.686787] 7f20: 0101010101010101 0000000000000004 0000000000000020 00000000000003f3
[   93.694544] 7f40: 0000007facb95664 0000007facda7030 0000007facc555d0 0000000000498378
[   93.702301] 7f60: 0000000000000000 000000002b424010 0000007facda0710 000000002b424090
[   93.710058] 7f80: 0000007fcc474698 0000000000498000 0000007fcc474ebb 0000000000474f58
[   93.717815] 7fa0: 0000000000498000 0000000000000000 0000000000000000 0000007fcc474550
[   93.725573] 7fc0: 00000000004104bc 0000007fcc474430 0000007facc555f4 0000000080000000
[   93.733330] 7fe0: 000000002b424090 0000000000000069 0950020128000244 4104000008000004
[   93.741084] Call trace:

The above output makes a debugger life a lot more easier.

Signed-off-by: Rohit Thapliyal 
Signed-off-by: Maninder Singh 
Reviewed-by: Catalin Marinas 
Signed-off-by: Will Deacon

arm64: Fix show_unhandled_signal_ratelimited usage

2015-07-03T16:03:06+00:00

Commit 86dca36e6ba introduced ratelimited usage for
'unhandled_signal' messages.
The commit checks the ratelimit irrespective of whether
the signal is handled or not, which is wrong and leads
to false reports like the below in dmesg :

__do_user_fault: 127 callbacks suppressed

Do the ratelimit check only if the signal is unhandled.

Fixes: 86dca36e6ba0 ("arm64: use private ratelimit state along with show_unhandled_signals")
Cc: Vladimir Murzin 
Signed-off-by: Suzuki K. Poulose 
Signed-off-by: Catalin Marinas

arm64: use private ratelimit state along with show_unhandled_signals

2015-06-19T15:26:15+00:00

printk_ratelimit() shares the ratelimiting state with other callers what
may lead to scenarios where at the time we want to print out debug
information we already limited, so nothing appears in the dmesg - this
makes exception-trace quite poor helper in debugging.

Additionally, we have imbalance with some messages limited with global
ratelimit state and other messages limited with their private state
defined via pr_*_ratelimited().

To address this inconsistency show_unhandled_signals_ratelimited()
macro is introduced and caller sites are converted to use it.

Signed-off-by: Vladimir Murzin 
Signed-off-by: Catalin Marinas

arm64: decode ESR_ELx.EC when reporting exceptions

2015-01-15T12:24:22+00:00

To aid the developer when something triggers an unexpected exception,
decode the ESR_ELx.EC field when logging an ESR_ELx value. This doesn't
tell the developer the specifics of the exception encoded in the
remaining IL and ISS bits, but it can be helpful to distinguish between
exception classes (e.g. SError and a data abort) without having to
manually decode the field, which can be tiresome.

Signed-off-by: Mark Rutland 
Acked-by: Catalin Marinas 
Reviewed-by: Christoffer Dall 
Cc: Marc Zyngier 
Cc: Peter Maydell 
Cc: Will Deacon

arm64: Add support for hooks to handle undefined instructions

2014-11-20T16:33:43+00:00

Add support to register hooks for undefined instructions. The handlers
will be called when the undefined instruction and the processor state
(as contained in pstate) match criteria used at registration.

Signed-off-by: Punit Agrawal 
Reviewed-by: Catalin Marinas 
Signed-off-by: Will Deacon

arm64: LLVMLinux: Use current_stack_pointer in kernel/traps.c

2014-09-08T13:39:19+00:00

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 
Signed-off-by: Mark Charlebois 
Reviewed-by: Olof Johansson 
Acked-by: Will Deacon 
Signed-off-by: Will Deacon