ARM: implement IRQ stacks

Now that we no longer rely on the stack pointer to access the current
task struct or thread info, we can implement support for IRQ stacks
cleanly as well.

Define a per-CPU

ARM: implement IRQ stacks

Now that we no longer rely on the stack pointer to access the current
task struct or thread info, we can implement support for IRQ stacks
cleanly as well.

Define a per-CPU IRQ stack and switch to this stack when taking an IRQ,
provided that we were not already using that stack in the interrupted
context. This is never the case for IRQs taken from user space, but ones
taken while running in the kernel could fire while one taken from user
space has not completed yet.

Signed-off-by: Ard Biesheuvel <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Tested-by: Keith Packard <[email protected]>
Acked-by: Nick Desaulniers <[email protected]>
Tested-by: Marc Zyngier <[email protected]>
Tested-by: Vladimir Murzin <[email protected]> # ARMv7M

show more ...

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 con

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 <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: Jessica Yu <[email protected]>
Cc: Sergey Senozhatsky <[email protected]>
Cc: John Ogness <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: Kees Cook <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Tested-by: Petr Mladek <[email protected]>
Reported-by: kernel test robot <[email protected]>
Acked-by: Andy Shevchenko <[email protected]>
Acked-by: Jessica Yu <[email protected]> # for module.{c,h}
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/e42070983637ac5e384f17fbdbe86d19c7b212a5.1623775748.git.chris@chrisdown.name

show more ...

arm/asm: add loglvl to c_backtrace()

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 t

arm/asm: add loglvl to c_backtrace()

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 c_backtrace() as a preparation for introducing
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: Russell King <[email protected]>
Cc: Will Deacon <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

ARM: 8897/1: check stmfd instruction using right shift

In the commit ef41b5c92498 ("ARM: make kernel oops easier to read"),
- .word 0xe92d0000 >> 10 @ stmfd sp!, {}
+

ARM: 8897/1: check stmfd instruction using right shift

In the commit ef41b5c92498 ("ARM: make kernel oops easier to read"),
- .word 0xe92d0000 >> 10 @ stmfd sp!, {}
+ .word 0xe92d0000 >> 11 @ stmfd sp!, {}
then the shift need to change to 11.

Signed-off-by: Lvqiang Huang <[email protected]>
Signed-off-by: Chunyan Zhang <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

Based on 2 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of th

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

Based on 2 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Enrico Weigelt <[email protected]>
Reviewed-by: Kate Stewart <[email protected]>
Reviewed-by: Allison Randal <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

ARM: fix backtrace

Recent kernels have changed their behaviour to be more inconsistent
when handling printk continuations. With todays kernels, the output
looks sane on the console, but dmesg split

ARM: fix backtrace

Recent kernels have changed their behaviour to be more inconsistent
when handling printk continuations. With todays kernels, the output
looks sane on the console, but dmesg splits individual printk()s which
do not have the KERN_CONT prefix into separate lines.

Since the assembly code is not trivial to add the KERN_CONT, and we
ideally want to avoid using KERN_CONT (as multiple printk()s can race
between different threads), convert the assembly dumping the register
values to C code, and have the C code build the output a line at a
time before dumping to the console.

This avoids the KERN_CONT issue, and also avoids situations where the
output is intermixed with other console activity.

Signed-off-by: Russell King <[email protected]>

show more ...

ARM: convert all "mov.* pc, reg" to "bx reg" for ARMv6+

ARMv6 and greater introduced a new instruction ("bx") which can be used
to return from function calls. Recent CPUs perform better when the
"b

ARM: convert all "mov.* pc, reg" to "bx reg" for ARMv6+

ARMv6 and greater introduced a new instruction ("bx") which can be used
to return from function calls. Recent CPUs perform better when the
"bx lr" instruction is used rather than the "mov pc, lr" instruction,
and this sequence is strongly recommended to be used by the ARM
architecture manual (section A.4.1.1).

We provide a new macro "ret" with all its variants for the condition
code which will resolve to the appropriate instruction.

Rather than doing this piecemeal, and miss some instances, change all
the "mov pc" instances to use the new macro, with the exception of
the "movs" instruction and the kprobes code. This allows us to detect
the "mov pc, lr" case and fix it up - and also gives us the possibility
of deploying this for other registers depending on the CPU selection.

Reported-by: Will Deacon <[email protected]>
Tested-by: Stephen Warren <[email protected]> # Tegra Jetson TK1
Tested-by: Robert Jarzmik <[email protected]> # mioa701_bootresume.S
Tested-by: Andrew Lunn <[email protected]> # Kirkwood
Tested-by: Shawn Guo <[email protected]>
Tested-by: Tony Lindgren <[email protected]> # OMAPs
Tested-by: Gregory CLEMENT <[email protected]> # Armada XP, 375, 385
Acked-by: Sekhar Nori <[email protected]> # DaVinci
Acked-by: Christoffer Dall <[email protected]> # kvm/hyp
Acked-by: Haojian Zhuang <[email protected]> # PXA3xx
Acked-by: Stefano Stabellini <[email protected]> # Xen
Tested-by: Uwe Kleine-König <[email protected]> # ARMv7M
Tested-by: Simon Horman <[email protected]> # Shmobile
Signed-off-by: Russell King <[email protected]>

show more ...

ARM: make kernel oops easier to read

We don't need the offset for the first function name in each backtrace
entry; this needlessly consumes screen space. This is virtually always
the first or secon

ARM: make kernel oops easier to read

We don't need the offset for the first function name in each backtrace
entry; this needlessly consumes screen space. This is virtually always
the first or second instruction in the called function.

Also, recognise stmfd instructions which include r10 as a valid stack
saving instruction, and when dumping the registers, dump six registers
per line rather than five, and fix the wrapping.

Signed-off-by: Russell King <[email protected]>

show more ...

ARM: 7068/1: process: change from __backtrace to dump_stack in show_regs

Currently, show_regs calls __backtrace which does
nothing if CONFIG_FRAME_POINTER is not set. Switch to
dump_stack which hand

ARM: 7068/1: process: change from __backtrace to dump_stack in show_regs

Currently, show_regs calls __backtrace which does
nothing if CONFIG_FRAME_POINTER is not set. Switch to
dump_stack which handles both CONFIG_FRAME_POINTER and
CONFIG_ARM_UNWIND correctly.

__backtrace is now superseded by dump_stack in general
and show_regs was the last caller so remove __backtrace
as well.

Signed-off-by: Laura Abbott <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

ARM: fix build error in arch/arm/kernel/process.c

/tmp/ccJ3ssZW.s: Assembler messages:
/tmp/ccJ3ssZW.s:1952: Error: can't resolve `.text' {.text section} - `.LFB1077'

This is caused because:

.sec

ARM: fix build error in arch/arm/kernel/process.c

/tmp/ccJ3ssZW.s: Assembler messages:
/tmp/ccJ3ssZW.s:1952: Error: can't resolve `.text' {.text section} - `.LFB1077'

This is caused because:

.section .data
.section .text
.section .text
.previous

does not return us to the .text section, but the .data section; this
makes use of .previous dangerous if the ordering of previous sections
is not known.

Fix up the other users of .previous; .pushsection and .popsection are
a safer pairing to use than .section and .previous.

Signed-off-by: Russell King <[email protected]>

show more ...

Thumb-2: Implement the unified arch/arm/lib functions

This patch adds the ARM/Thumb-2 unified support for the arch/arm/lib/*
files.

Signed-off-by: Catalin Marinas <[email protected]>

[ARM] 5227/1: Add the ENDPROC declarations to the .S files

This declaration specifies the "function" type and size for various
assembly functions, mainly needed for generating the correct branch
ins

[ARM] 5227/1: Add the ENDPROC declarations to the .S files

This declaration specifies the "function" type and size for various
assembly functions, mainly needed for generating the correct branch
instructions in Thumb-2.

Signed-off-by: Catalin Marinas <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

[ARM] Add ability to dump exception stacks to kernel backtraces

Signed-off-by: Russell King <[email protected]>

Remove obsolete #include <linux/config.h>

Signed-off-by: Jörn Engel <[email protected]>
Signed-off-by: Adrian Bunk <[email protected]>

[ARM] nommu: backtrace code must not reference a discarded section

The code in "1007:" is in the .fixup section, which in the mmuless
case is discarded. Since this code is referenced from the .text

[ARM] nommu: backtrace code must not reference a discarded section

The code in "1007:" is in the .fixup section, which in the mmuless
case is discarded. Since this code is referenced from the .text
section, it causes an link error. Move this code into the .text
section instead.

Signed-off-by: Russell King <[email protected]>

show more ...

[ARM] Remove LOADREGS macro

As for RETINSTR, LOADREGS is a left-over from the 26-bit days.
Remove it.

Signed-off-by: Russell King <[email protected]>

[ARM] 3524/1: ARM EABI: more 64-bit aligned stack fixes

Patch from Nicolas Pitre

Assembly code that calls C code must ensure the C code sees a 64-bit
aligned stack pointer.

Signed-off-by: Nicolas

[ARM] 3524/1: ARM EABI: more 64-bit aligned stack fixes

Patch from Nicolas Pitre

Assembly code that calls C code must ensure the C code sees a 64-bit
aligned stack pointer.

Signed-off-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

[ARM] 3399/1: Fix link problem when CONFIG_PRINTK is disabled

Patch from Malcolm Parsons

Printking a backtrace requires printk, so disable backtrace code
when printk is disabled.

Without this patc

[ARM] 3399/1: Fix link problem when CONFIG_PRINTK is disabled

Patch from Malcolm Parsons

Printking a backtrace requires printk, so disable backtrace code
when printk is disabled.

Without this patch, a kernel with CONFIG_PRINTK disabled does not link:

arch/arm/lib/lib.a(backtrace.o): In function `c_backtrace':
arch/arm/lib/backtrace.S:(.text+0x108): undefined reference to `printk'
arch/arm/lib/backtrace.S:(.text+0x11c): undefined reference to `printk'
arch/arm/lib/lib.a(backtrace.o):(.fixup+0x8): undefined reference to `printk'

Signed-off-by: Malcolm Parsons <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in

Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!

show more ...