linux-toradex.git/kernel/panic.c, branch v5.10-rc3

panic: dump registers on panic_on_warn

2020-10-16T18:11:22+00:00

Currently we print stack and registers for ordinary warnings but we do not
for panic_on_warn which looks as oversight - panic() will reboot the
machine but won't print registers.

This moves printing of registers and modules earlier.

This does not move the stack dumping as panic() dumps it.

Signed-off-by: Alexey Kardashevskiy 
Signed-off-by: Andrew Morton 
Reviewed-by: Kees Cook 
Cc: Douglas Anderson 
Cc: Ingo Molnar 
Cc: Kees Cook 
Cc: Rafael Aquini 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Cc: Nicholas Piggin 
Link: https://lkml.kernel.org/r/20200804095054.68724-1-aik@ozlabs.ru
Signed-off-by: Linus Torvalds

panic: make print_oops_end_marker() static

2020-08-12T17:58:02+00:00

Since print_oops_end_marker() is not used externally, also remove it in
kernel.h at the same time.

Signed-off-by: Yue Hu 
Signed-off-by: Andrew Morton 
Cc: Kees Cook 
Link: http://lkml.kernel.org/r/20200724011516.12756-1-zbestahu@gmail.com
Signed-off-by: Linus Torvalds

kernel/panic.c: make oops_may_print() return bool

2020-08-12T17:58:01+00:00

The return value of oops_may_print() is true or false, so change its type
to reflect that.

Signed-off-by: Tiezhu Yang 
Signed-off-by: Andrew Morton 
Reviewed-by: Kees Cook 
Cc: Xuefeng Li 
Link: http://lkml.kernel.org/r/1591103358-32087-1-git-send-email-yangtiezhu@loongson.cn
Signed-off-by: Linus Torvalds

bug: Annotate WARN/BUG/stackfail as noinstr safe

2020-06-11T13:14:36+00:00

Warnings, bugs and stack protection fails from noinstr sections, e.g. low
level and early entry code, are likely to be fatal.

Mark them as "safe" to be invoked from noinstr protected code to avoid
annotating all usage sites. Getting the information out is important.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Alexandre Chartre 
Acked-by: Peter Zijlstra 
Link: https://lkml.kernel.org/r/20200505134100.376598577@linutronix.de

panic: add sysctl to dump all CPUs backtraces on oops event

2020-06-08T18:05:56+00:00

Usually when the kernel reaches an oops condition, it's a point of no
return; in case not enough debug information is available in the kernel
splat, one of the last resorts would be to collect a kernel crash dump
and analyze it.  The problem with this approach is that in order to
collect the dump, a panic is required (to kexec-load the crash kernel).
When in an environment of multiple virtual machines, users may prefer to
try living with the oops, at least until being able to properly shutdown
their VMs / finish their important tasks.

This patch implements a way to collect a bit more debug details when an
oops event is reached, by printing all the CPUs backtraces through the
usage of NMIs (on architectures that support that).  The sysctl added
(and documented) here was called "oops_all_cpu_backtrace", and when set
will (as the name suggests) dump all CPUs backtraces.

Far from ideal, this may be the last option though for users that for
some reason cannot panic on oops.  Most of times oopses are clear enough
to indicate the kernel portion that must be investigated, but in virtual
environments it's possible to observe hypervisor/KVM issues that could
lead to oopses shown in other guests CPUs (like virtual APIC crashes).
This patch hence aims to help debug such complex issues without
resorting to kdump.

Signed-off-by: Guilherme G. Piccoli 
Signed-off-by: Andrew Morton 
Reviewed-by: Kees Cook 
Cc: Luis Chamberlain 
Cc: Iurii Zaikin 
Cc: Thomas Gleixner 
Cc: Vlastimil Babka 
Cc: Randy Dunlap 
Cc: Matthew Wilcox 
Link: http://lkml.kernel.org/r/20200327224116.21030-1-gpiccoli@canonical.com
Signed-off-by: Linus Torvalds

kernel: add panic_on_taint

2020-06-08T18:05:56+00:00

Analogously to the introduction of panic_on_warn, this patch introduces
a kernel option named panic_on_taint in order to provide a simple and
generic way to stop execution and catch a coredump when the kernel gets
tainted by any given flag.

This is useful for debugging sessions as it avoids having to rebuild the
kernel to explicitly add calls to panic() into the code sites that
introduce the taint flags of interest.

For instance, if one is interested in proceeding with a post-mortem
analysis at the point a given code path is hitting a bad page (i.e.
unaccount_page_cache_page(), or slab_bug()), a coredump can be collected
by rebooting the kernel with 'panic_on_taint=0x20' amended to the
command line.

Another, perhaps less frequent, use for this option would be as a means
for assuring a security policy case where only a subset of taints, or no
single taint (in paranoid mode), is allowed for the running system.  The
optional switch 'nousertaint' is handy in this particular scenario, as
it will avoid userspace induced crashes by writes to sysctl interface
/proc/sys/kernel/tainted causing false positive hits for such policies.

[akpm@linux-foundation.org: tweak kernel-parameters.txt wording]

Suggested-by: Qian Cai 
Signed-off-by: Rafael Aquini 
Signed-off-by: Andrew Morton 
Reviewed-by: Luis Chamberlain 
Cc: Dave Young 
Cc: Baoquan He 
Cc: Jonathan Corbet 
Cc: Kees Cook 
Cc: Randy Dunlap 
Cc: "Theodore Ts'o" 
Cc: Adrian Bunk 
Cc: Greg Kroah-Hartman 
Cc: Laura Abbott 
Cc: Jeff Mahoney 
Cc: Jiri Kosina 
Cc: Takashi Iwai 
Link: http://lkml.kernel.org/r/20200515175502.146720-1-aquini@redhat.com
Signed-off-by: Linus Torvalds

locking/refcount: Remove unused 'refcount_error_report()' function

2019-11-25T08:15:42+00:00

'refcount_error_report()' has no callers. Remove it.

Signed-off-by: Will Deacon 
Reviewed-by: Ard Biesheuvel 
Acked-by: Kees Cook 
Tested-by: Hanjun Guo 
Cc: Ard Biesheuvel 
Cc: Elena Reshetova 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: https://lkml.kernel.org/r/20191121115902.2551-10-will@kernel.org
Signed-off-by: Ingo Molnar

panic: ensure preemption is disabled during panic()

2019-10-07T22:47:19+00:00

Calling 'panic()' on a kernel with CONFIG_PREEMPT=y can leave the
calling CPU in an infinite loop, but with interrupts and preemption
enabled.  From this state, userspace can continue to be scheduled,
despite the system being "dead" as far as the kernel is concerned.

This is easily reproducible on arm64 when booting with "nosmp" on the
command line; a couple of shell scripts print out a periodic "Ping"
message whilst another triggers a crash by writing to
/proc/sysrq-trigger:

  | sysrq: Trigger a crash
  | Kernel panic - not syncing: sysrq triggered crash
  | CPU: 0 PID: 1 Comm: init Not tainted 5.2.15 #1
  | Hardware name: linux,dummy-virt (DT)
  | Call trace:
  |  dump_backtrace+0x0/0x148
  |  show_stack+0x14/0x20
  |  dump_stack+0xa0/0xc4
  |  panic+0x140/0x32c
  |  sysrq_handle_reboot+0x0/0x20
  |  __handle_sysrq+0x124/0x190
  |  write_sysrq_trigger+0x64/0x88
  |  proc_reg_write+0x60/0xa8
  |  __vfs_write+0x18/0x40
  |  vfs_write+0xa4/0x1b8
  |  ksys_write+0x64/0xf0
  |  __arm64_sys_write+0x14/0x20
  |  el0_svc_common.constprop.0+0xb0/0x168
  |  el0_svc_handler+0x28/0x78
  |  el0_svc+0x8/0xc
  | Kernel Offset: disabled
  | CPU features: 0x0002,24002004
  | Memory Limit: none
  | ---[ end Kernel panic - not syncing: sysrq triggered crash ]---
  |  Ping 2!
  |  Ping 1!
  |  Ping 1!
  |  Ping 2!

The issue can also be triggered on x86 kernels if CONFIG_SMP=n,
otherwise local interrupts are disabled in 'smp_send_stop()'.

Disable preemption in 'panic()' before re-enabling interrupts.

Link: http://lkml.kernel.org/r/20191002123538.22609-1-will@kernel.org
Link: https://lore.kernel.org/r/BX1W47JXPMR8.58IYW53H6M5N@dragonstone
Signed-off-by: Will Deacon 
Reported-by: Xogium 
Reviewed-by: Kees Cook 
Cc: Russell King 
Cc: Greg Kroah-Hartman 
Cc: Ingo Molnar 
Cc: Petr Mladek 
Cc: Feng Tang 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

bug: consolidate __WARN_FLAGS usage

2019-09-26T00:51:41+00:00

Instead of having separate tests for __WARN_FLAGS, merge the two #ifdef
blocks and replace the synonym WANT_WARN_ON_SLOWPATH macro.

Link: http://lkml.kernel.org/r/20190819234111.9019-7-keescook@chromium.org
Signed-off-by: Kees Cook 
Cc: Arnd Bergmann 
Cc: Borislav Petkov 
Cc: Christophe Leroy 
Cc: Drew Davenport 
Cc: Feng Tang 
Cc: Mauro Carvalho Chehab 
Cc: Peter Zijlstra 
Cc: Petr Mladek 
Cc: "Steven Rostedt (VMware)" 
Cc: YueHaibing 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

bug: lift "cut here" out of __warn()

2019-09-26T00:51:40+00:00

In preparation for cleaning up "cut here", move the "cut here" logic up
out of __warn() and into callers that pass non-NULL args.  For anyone
looking closely, there are two callers that pass NULL args: one already
explicitly prints "cut here".  The remaining case is covered by how a WARN
is built, which will be cleaned up in the next patch.

Link: http://lkml.kernel.org/r/20190819234111.9019-5-keescook@chromium.org
Signed-off-by: Kees Cook 
Cc: Arnd Bergmann 
Cc: Borislav Petkov 
Cc: Christophe Leroy 
Cc: Drew Davenport 
Cc: Feng Tang 
Cc: Mauro Carvalho Chehab 
Cc: Peter Zijlstra 
Cc: Petr Mladek 
Cc: "Steven Rostedt (VMware)" 
Cc: YueHaibing 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds