2019-06-04 11:11:33 +03:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2010-05-21 21:06:42 +04:00
|
|
|
/*
|
|
|
|
|
* linux/arch/arm/kernel/entry-v7m.S
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2008 ARM Ltd.
|
|
|
|
|
*
|
|
|
|
|
* Low-level vector interface routines for the ARMv7-M architecture
|
|
|
|
|
*/
|
|
|
|
|
#include <asm/memory.h>
|
|
|
|
|
#include <asm/glue.h>
|
|
|
|
|
#include <asm/thread_notify.h>
|
|
|
|
|
#include <asm/v7m.h>
|
|
|
|
|
|
|
|
|
|
#include "entry-header.S"
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_TRACE_IRQFLAGS
|
|
|
|
|
#error "CONFIG_TRACE_IRQFLAGS not supported on the current ARMv7M implementation"
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
__invalid_entry:
|
|
|
|
|
v7m_exception_entry
|
2015-01-28 18:05:04 +03:00
|
|
|
#ifdef CONFIG_PRINTK
|
2010-05-21 21:06:42 +04:00
|
|
|
adr r0, strerr
|
|
|
|
|
mrs r1, ipsr
|
|
|
|
|
mov r2, lr
|
printk: Userspace format indexing support
We have a number of systems industry-wide that have a subset of their
functionality that works as follows:
1. Receive a message from local kmsg, serial console, or netconsole;
2. Apply a set of rules to classify the message;
3. Do something based on this classification (like scheduling a
remediation for the machine), rinse, and repeat.
As a couple of examples of places we have this implemented just inside
Facebook, although this isn't a Facebook-specific problem, we have this
inside our netconsole processing (for alarm classification), and as part
of our machine health checking. We use these messages to determine
fairly important metrics around production health, and it's important
that we get them right.
While for some kinds of issues we have counters, tracepoints, or metrics
with a stable interface which can reliably indicate the issue, in order
to react to production issues quickly we need to work with the interface
which most kernel developers naturally use when developing: printk.
Most production issues come from unexpected phenomena, and as such
usually the code in question doesn't have easily usable tracepoints or
other counters available for the specific problem being mitigated. We
have a number of lines of monitoring defence against problems in
production (host metrics, process metrics, service metrics, etc), and
where it's not feasible to reliably monitor at another level, this kind
of pragmatic netconsole monitoring is essential.
As one would expect, monitoring using printk is rather brittle for a
number of reasons -- most notably that the message might disappear
entirely in a new version of the kernel, or that the message may change
in some way that the regex or other classification methods start to
silently fail.
One factor that makes this even harder is that, under normal operation,
many of these messages are never expected to be hit. For example, there
may be a rare hardware bug which one wants to detect if it was to ever
happen again, but its recurrence is not likely or anticipated. This
precludes using something like checking whether the printk in question
was printed somewhere fleetwide recently to determine whether the
message in question is still present or not, since we don't anticipate
that it should be printed anywhere, but still need to monitor for its
future presence in the long-term.
This class of issue has happened on a number of occasions, causing
unhealthy machines with hardware issues to remain in production for
longer than ideal. As a recent example, some monitoring around
blk_update_request fell out of date and caused semi-broken machines to
remain in production for longer than would be desirable.
Searching through the codebase to find the message is also extremely
fragile, because many of the messages are further constructed beyond
their callsite (eg. btrfs_printk and other module-specific wrappers,
each with their own functionality). Even if they aren't, guessing the
format and formulation of the underlying message based on the aesthetics
of the message emitted is not a recipe for success at scale, and our
previous issues with fleetwide machine health checking demonstrate as
much.
This provides a solution to the issue of silently changed or deleted
printks: we record pointers to all printk format strings known at
compile time into a new .printk_index section, both in vmlinux and
modules. At runtime, this can then be iterated by looking at
<debugfs>/printk/index/<module>, which emits the following format, both
readable by humans and able to be parsed by machines:
$ head -1 vmlinux; shuf -n 5 vmlinux
# <level[,flags]> filename:line function "format"
<5> block/blk-settings.c:661 disk_stack_limits "%s: Warning: Device %s is misaligned\n"
<4> kernel/trace/trace.c:8296 trace_create_file "Could not create tracefs '%s' entry\n"
<6> arch/x86/kernel/hpet.c:144 _hpet_print_config "hpet: %s(%d):\n"
<6> init/do_mounts.c:605 prepare_namespace "Waiting for root device %s...\n"
<6> drivers/acpi/osl.c:1410 acpi_no_auto_serialize_setup "ACPI: auto-serialization disabled\n"
This mitigates the majority of cases where we have a highly-specific
printk which we want to match on, as we can now enumerate and check
whether the format changed or the printk callsite disappeared entirely
in userspace. This allows us to catch changes to printks we monitor
earlier and decide what to do about it before it becomes problematic.
There is no additional runtime cost for printk callers or printk itself,
and the assembly generated is exactly the same.
Signed-off-by: Chris Down <chris@chrisdown.name>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Jessica Yu <jeyu@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kees Cook <keescook@chromium.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Tested-by: Petr Mladek <pmladek@suse.com>
Reported-by: kernel test robot <lkp@intel.com>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Jessica Yu <jeyu@kernel.org> # for module.{c,h}
Signed-off-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/e42070983637ac5e384f17fbdbe86d19c7b212a5.1623775748.git.chris@chrisdown.name
2021-06-15 19:52:53 +03:00
|
|
|
bl _printk
|
2015-01-28 18:05:04 +03:00
|
|
|
#endif
|
2010-05-21 21:06:42 +04:00
|
|
|
mov r0, sp
|
|
|
|
|
bl show_regs
|
|
|
|
|
1: b 1b
|
|
|
|
|
ENDPROC(__invalid_entry)
|
|
|
|
|
|
|
|
|
|
strerr: .asciz "\nUnhandled exception: IPSR = %08lx LR = %08lx\n"
|
|
|
|
|
|
|
|
|
|
.align 2
|
|
|
|
|
__irq_entry:
|
|
|
|
|
v7m_exception_entry
|
|
|
|
|
|
|
|
|
|
@
|
|
|
|
|
@ Invoke the IRQ handler
|
|
|
|
|
@
|
2021-12-01 14:02:59 +03:00
|
|
|
mov r0, sp
|
2021-12-02 11:36:59 +03:00
|
|
|
ldr_this_cpu sp, irq_stack_ptr, r1, r2
|
|
|
|
|
|
|
|
|
|
@
|
|
|
|
|
@ If we took the interrupt while running in the kernel, we may already
|
|
|
|
|
@ be using the IRQ stack, so revert to the original value in that case.
|
|
|
|
|
@
|
|
|
|
|
subs r2, sp, r0 @ SP above bottom of IRQ stack?
|
|
|
|
|
rsbscs r2, r2, #THREAD_SIZE @ ... and below the top?
|
|
|
|
|
movcs sp, r0
|
|
|
|
|
|
|
|
|
|
push {r0, lr} @ preserve LR and original SP
|
|
|
|
|
|
2021-12-01 14:02:59 +03:00
|
|
|
@ routine called with r0 = struct pt_regs *
|
|
|
|
|
bl generic_handle_arch_irq
|
2010-05-21 21:06:42 +04:00
|
|
|
|
2021-12-02 11:36:59 +03:00
|
|
|
pop {r0, lr}
|
|
|
|
|
mov sp, r0
|
|
|
|
|
|
2010-05-21 21:06:42 +04:00
|
|
|
@
|
|
|
|
|
@ Check for any pending work if returning to user
|
|
|
|
|
@
|
|
|
|
|
ldr r1, =BASEADDR_V7M_SCB
|
|
|
|
|
ldr r0, [r1, V7M_SCB_ICSR]
|
|
|
|
|
tst r0, V7M_SCB_ICSR_RETTOBASE
|
|
|
|
|
beq 2f
|
|
|
|
|
|
|
|
|
|
get_thread_info tsk
|
|
|
|
|
ldr r2, [tsk, #TI_FLAGS]
|
2020-10-10 01:00:49 +03:00
|
|
|
movs r2, r2, lsl #16
|
2010-05-21 21:06:42 +04:00
|
|
|
beq 2f @ no work pending
|
|
|
|
|
mov r0, #V7M_SCB_ICSR_PENDSVSET
|
|
|
|
|
str r0, [r1, V7M_SCB_ICSR] @ raise PendSV
|
|
|
|
|
|
|
|
|
|
2:
|
|
|
|
|
@ registers r0-r3 and r12 are automatically restored on exception
|
|
|
|
|
@ return. r4-r7 were not clobbered in v7m_exception_entry so for
|
|
|
|
|
@ correctness they don't need to be restored. So only r8-r11 must be
|
|
|
|
|
@ restored here. The easiest way to do so is to restore r0-r7, too.
|
|
|
|
|
ldmia sp!, {r0-r11}
|
2016-05-10 18:34:27 +03:00
|
|
|
add sp, #PT_REGS_SIZE-S_IP
|
2010-05-21 21:06:42 +04:00
|
|
|
cpsie i
|
|
|
|
|
bx lr
|
|
|
|
|
ENDPROC(__irq_entry)
|
|
|
|
|
|
|
|
|
|
__pendsv_entry:
|
|
|
|
|
v7m_exception_entry
|
|
|
|
|
|
|
|
|
|
ldr r1, =BASEADDR_V7M_SCB
|
|
|
|
|
mov r0, #V7M_SCB_ICSR_PENDSVCLR
|
|
|
|
|
str r0, [r1, V7M_SCB_ICSR] @ clear PendSV
|
|
|
|
|
|
|
|
|
|
@ execute the pending work, including reschedule
|
|
|
|
|
get_thread_info tsk
|
|
|
|
|
mov why, #0
|
2015-10-30 23:08:05 +03:00
|
|
|
b ret_to_user_from_irq
|
2010-05-21 21:06:42 +04:00
|
|
|
ENDPROC(__pendsv_entry)
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Register switch for ARMv7-M processors.
|
|
|
|
|
* r0 = previous task_struct, r1 = previous thread_info, r2 = next thread_info
|
|
|
|
|
* previous and next are guaranteed not to be the same.
|
|
|
|
|
*/
|
|
|
|
|
ENTRY(__switch_to)
|
|
|
|
|
.fnstart
|
|
|
|
|
.cantunwind
|
|
|
|
|
add ip, r1, #TI_CPU_SAVE
|
|
|
|
|
stmia ip!, {r4 - r11} @ Store most regs on stack
|
|
|
|
|
str sp, [ip], #4
|
|
|
|
|
str lr, [ip], #4
|
|
|
|
|
mov r5, r0
|
ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems
On UP systems, only a single task can be 'current' at the same time,
which means we can use a global variable to track it. This means we can
also enable THREAD_INFO_IN_TASK for those systems, as in that case,
thread_info is accessed via current rather than the other way around,
removing the need to store thread_info at the base of the task stack.
This, in turn, permits us to enable IRQ stacks and vmap'ed stacks on UP
systems as well.
To partially mitigate the performance overhead of this arrangement, use
a ADD/ADD/LDR sequence with the appropriate PC-relative group
relocations to load the value of current when needed. This means that
accessing current will still only require a single load as before,
avoiding the need for a literal to carry the address of the global
variable in each function. However, accessing thread_info will now
require this load as well.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-11-24 16:08:11 +03:00
|
|
|
mov r6, r2 @ Preserve 'next'
|
2010-05-21 21:06:42 +04:00
|
|
|
add r4, r2, #TI_CPU_SAVE
|
|
|
|
|
ldr r0, =thread_notify_head
|
|
|
|
|
mov r1, #THREAD_NOTIFY_SWITCH
|
|
|
|
|
bl atomic_notifier_call_chain
|
|
|
|
|
mov r0, r5
|
ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems
On UP systems, only a single task can be 'current' at the same time,
which means we can use a global variable to track it. This means we can
also enable THREAD_INFO_IN_TASK for those systems, as in that case,
thread_info is accessed via current rather than the other way around,
removing the need to store thread_info at the base of the task stack.
This, in turn, permits us to enable IRQ stacks and vmap'ed stacks on UP
systems as well.
To partially mitigate the performance overhead of this arrangement, use
a ADD/ADD/LDR sequence with the appropriate PC-relative group
relocations to load the value of current when needed. This means that
accessing current will still only require a single load as before,
avoiding the need for a literal to carry the address of the global
variable in each function. However, accessing thread_info will now
require this load as well.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-11-24 16:08:11 +03:00
|
|
|
mov r1, r6
|
|
|
|
|
ldmia r4, {r4 - r12, lr} @ Load all regs saved previously
|
|
|
|
|
set_current r1, r2
|
|
|
|
|
mov sp, ip
|
|
|
|
|
bx lr
|
2010-05-21 21:06:42 +04:00
|
|
|
.fnend
|
|
|
|
|
ENDPROC(__switch_to)
|
|
|
|
|
|
|
|
|
|
.data
|
2015-04-10 11:46:46 +03:00
|
|
|
#if CONFIG_CPU_V7M_NUM_IRQ <= 112
|
|
|
|
|
.align 9
|
|
|
|
|
#else
|
|
|
|
|
.align 10
|
|
|
|
|
#endif
|
|
|
|
|
|
2010-05-21 21:06:42 +04:00
|
|
|
/*
|
2015-04-10 11:46:46 +03:00
|
|
|
* Vector table (Natural alignment need to be ensured)
|
2010-05-21 21:06:42 +04:00
|
|
|
*/
|
|
|
|
|
ENTRY(vector_table)
|
|
|
|
|
.long 0 @ 0 - Reset stack pointer
|
|
|
|
|
.long __invalid_entry @ 1 - Reset
|
|
|
|
|
.long __invalid_entry @ 2 - NMI
|
|
|
|
|
.long __invalid_entry @ 3 - HardFault
|
|
|
|
|
.long __invalid_entry @ 4 - MemManage
|
|
|
|
|
.long __invalid_entry @ 5 - BusFault
|
|
|
|
|
.long __invalid_entry @ 6 - UsageFault
|
|
|
|
|
.long __invalid_entry @ 7 - Reserved
|
|
|
|
|
.long __invalid_entry @ 8 - Reserved
|
|
|
|
|
.long __invalid_entry @ 9 - Reserved
|
|
|
|
|
.long __invalid_entry @ 10 - Reserved
|
|
|
|
|
.long vector_swi @ 11 - SVCall
|
|
|
|
|
.long __invalid_entry @ 12 - Debug Monitor
|
|
|
|
|
.long __invalid_entry @ 13 - Reserved
|
|
|
|
|
.long __pendsv_entry @ 14 - PendSV
|
|
|
|
|
.long __invalid_entry @ 15 - SysTick
|
2015-04-10 11:46:46 +03:00
|
|
|
.rept CONFIG_CPU_V7M_NUM_IRQ
|
|
|
|
|
.long __irq_entry @ External Interrupts
|
2010-05-21 21:06:42 +04:00
|
|
|
.endr
|
2019-01-25 17:18:37 +03:00
|
|
|
.align 2
|
|
|
|
|
.globl exc_ret
|
|
|
|
|
exc_ret:
|
|
|
|
|
.space 4
|
