linux-stable.git/kernel/panic.c, branch v5.4.285

panic: Flush kernel log buffer at the end

2024-04-13T10:51:37+00:00

[ Upstream commit d988d9a9b9d180bfd5c1d353b3b176cb90d6861b ]

If the kernel crashes in a context where printk() calls always
defer printing (such as in NMI or inside a printk_safe section)
then the final panic messages will be deferred to irq_work. But
if irq_work is not available, the messages will not get printed
unless explicitly flushed. The result is that the final
"end Kernel panic" banner does not get printed.

Add one final flush after the last printk() call to make sure
the final panic messages make it out as well.

Signed-off-by: John Ogness 
Reviewed-by: Petr Mladek 
Link: https://lore.kernel.org/r/20240207134103.1357162-14-john.ogness@linutronix.de
Signed-off-by: Petr Mladek 
Signed-off-by: Sasha Levin

exit: Use READ_ONCE() for all oops/warn limit reads

2023-02-06T06:52:50+00:00

commit 7535b832c6399b5ebfc5b53af5c51dd915ee2538 upstream.

Use a temporary variable to take full advantage of READ_ONCE() behavior.
Without this, the report (and even the test) might be out of sync with
the initial test.

Reported-by: Peter Zijlstra 
Link: https://lore.kernel.org/lkml/Y5x7GXeluFmZ8E0E@hirez.programming.kicks-ass.net
Fixes: 9fc9e278a5c0 ("panic: Introduce warn_limit")
Fixes: d4ccd54d28d3 ("exit: Put an upper limit on how often we can oops")
Cc: "Eric W. Biederman" 
Cc: Jann Horn 
Cc: Arnd Bergmann 
Cc: Petr Mladek 
Cc: Andrew Morton 
Cc: Luis Chamberlain 
Cc: Marco Elver 
Cc: tangmeng 
Cc: Sebastian Andrzej Siewior 
Cc: Tiezhu Yang 
Signed-off-by: Kees Cook 
Signed-off-by: Eric Biggers 
Signed-off-by: Sasha Levin

panic: Expose "warn_count" to sysfs

2023-02-06T06:52:50+00:00

commit 8b05aa26336113c4cea25f1c333ee8cd4fc212a6 upstream.

Since Warn count is now tracked and is a fairly interesting signal, add
the entry /sys/kernel/warn_count to expose it to userspace.

Cc: Petr Mladek 
Cc: Andrew Morton 
Cc: tangmeng 
Cc: "Guilherme G. Piccoli" 
Cc: Sebastian Andrzej Siewior 
Cc: Tiezhu Yang 
Reviewed-by: Luis Chamberlain 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221117234328.594699-6-keescook@chromium.org
Signed-off-by: Eric Biggers 
Signed-off-by: Sasha Levin

panic: Introduce warn_limit

2023-02-06T06:52:50+00:00

commit 9fc9e278a5c0b708eeffaf47d6eb0c82aa74ed78 upstream.

Like oops_limit, add warn_limit for limiting the number of warnings when
panic_on_warn is not set.

Cc: Jonathan Corbet 
Cc: Andrew Morton 
Cc: Baolin Wang 
Cc: "Jason A. Donenfeld" 
Cc: Eric Biggers 
Cc: Huang Ying 
Cc: Petr Mladek 
Cc: tangmeng 
Cc: "Guilherme G. Piccoli" 
Cc: Tiezhu Yang 
Cc: Sebastian Andrzej Siewior 
Cc: linux-doc@vger.kernel.org
Reviewed-by: Luis Chamberlain 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221117234328.594699-5-keescook@chromium.org
Signed-off-by: Eric Biggers 
Signed-off-by: Sasha Levin

panic: Consolidate open-coded panic_on_warn checks

2023-02-06T06:52:50+00:00

commit 79cc1ba7badf9e7a12af99695a557e9ce27ee967 upstream.

Several run-time checkers (KASAN, UBSAN, KFENCE, KCSAN, sched) roll
their own warnings, and each check "panic_on_warn". Consolidate this
into a single function so that future instrumentation can be added in
a single location.

Cc: Marco Elver 
Cc: Dmitry Vyukov 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Juri Lelli 
Cc: Vincent Guittot 
Cc: Dietmar Eggemann 
Cc: Steven Rostedt 
Cc: Ben Segall 
Cc: Mel Gorman 
Cc: Daniel Bristot de Oliveira 
Cc: Valentin Schneider 
Cc: Andrey Ryabinin 
Cc: Alexander Potapenko 
Cc: Andrey Konovalov 
Cc: Vincenzo Frascino 
Cc: Andrew Morton 
Cc: David Gow 
Cc: tangmeng 
Cc: Jann Horn 
Cc: Shuah Khan 
Cc: Petr Mladek 
Cc: "Paul E. McKenney" 
Cc: Sebastian Andrzej Siewior 
Cc: "Guilherme G. Piccoli" 
Cc: Tiezhu Yang 
Cc: kasan-dev@googlegroups.com
Cc: linux-mm@kvack.org
Reviewed-by: Luis Chamberlain 
Signed-off-by: Kees Cook 
Reviewed-by: Marco Elver 
Reviewed-by: Andrey Konovalov 
Link: https://lore.kernel.org/r/20221117234328.594699-4-keescook@chromium.org
Signed-off-by: Eric Biggers 
Signed-off-by: Sasha Levin

panic: unset panic_on_warn inside panic()

2023-02-06T06:52:48+00:00

commit 1a2383e8b84c0451fd9b1eec3b9aab16f30b597c upstream.

In the current code, the following three places need to unset
panic_on_warn before calling panic() to avoid recursive panics:

kernel/kcsan/report.c: print_report()
kernel/sched/core.c: __schedule_bug()
mm/kfence/report.c: kfence_report_error()

In order to avoid copy-pasting "panic_on_warn = 0" all over the places,
it is better to move it inside panic() and then remove it from the other
places.

Link: https://lkml.kernel.org/r/1644324666-15947-4-git-send-email-yangtiezhu@loongson.cn
Signed-off-by: Tiezhu Yang 
Reviewed-by: Marco Elver 
Cc: Andrey Ryabinin 
Cc: Baoquan He 
Cc: Jonathan Corbet 
Cc: Xuefeng Li 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Eric Biggers 
Signed-off-by: Sasha Levin

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

bug: consolidate warn_slowpath_fmt() usage

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

Instead of having a separate helper for no printk output, just consolidate
the logic into warn_slowpath_fmt().

Link: http://lkml.kernel.org/r/20190819234111.9019-4-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