License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2010-05-07 21:11:44 +00:00
|
|
|
/*
|
|
|
|
* Detect hard and soft lockups on a system
|
|
|
|
*
|
|
|
|
* started by Don Zickus, Copyright (C) 2010 Red Hat, Inc.
|
|
|
|
*
|
2012-02-09 22:42:22 +00:00
|
|
|
* Note: Most of this code is borrowed heavily from the original softlockup
|
|
|
|
* detector, so thanks to Ingo for the initial implementation.
|
|
|
|
* Some chunks also taken from the old x86-specific nmi watchdog code, thanks
|
2010-05-07 21:11:44 +00:00
|
|
|
* to those contributors as well.
|
|
|
|
*/
|
|
|
|
|
2017-07-14 21:49:46 +00:00
|
|
|
#define pr_fmt(fmt) "watchdog: " fmt
|
2012-03-23 22:01:55 +00:00
|
|
|
|
2010-05-07 21:11:44 +00:00
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/cpu.h>
|
|
|
|
#include <linux/nmi.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/sysctl.h>
|
2015-06-24 23:55:45 +00:00
|
|
|
#include <linux/tick.h>
|
2017-02-01 15:36:40 +00:00
|
|
|
#include <linux/sched/clock.h>
|
2017-02-08 17:51:35 +00:00
|
|
|
#include <linux/sched/debug.h>
|
2017-10-27 02:42:28 +00:00
|
|
|
#include <linux/sched/isolation.h>
|
2018-06-07 08:52:03 +00:00
|
|
|
#include <linux/stop_machine.h>
|
2010-05-07 21:11:44 +00:00
|
|
|
|
|
|
|
#include <asm/irq_regs.h>
|
2012-03-10 19:37:28 +00:00
|
|
|
#include <linux/kvm_para.h>
|
2010-05-07 21:11:44 +00:00
|
|
|
|
2017-09-12 19:37:01 +00:00
|
|
|
static DEFINE_MUTEX(watchdog_mutex);
|
2015-05-18 09:31:50 +00:00
|
|
|
|
2017-07-12 21:35:46 +00:00
|
|
|
#if defined(CONFIG_HARDLOCKUP_DETECTOR) || defined(CONFIG_HAVE_NMI_WATCHDOG)
|
2023-05-19 17:18:36 +00:00
|
|
|
# define WATCHDOG_HARDLOCKUP_DEFAULT 1
|
2015-04-14 22:43:55 +00:00
|
|
|
#else
|
2023-05-19 17:18:36 +00:00
|
|
|
# define WATCHDOG_HARDLOCKUP_DEFAULT 0
|
2015-04-14 22:43:55 +00:00
|
|
|
#endif
|
2017-07-12 21:35:46 +00:00
|
|
|
|
2017-09-12 19:37:17 +00:00
|
|
|
unsigned long __read_mostly watchdog_enabled;
|
|
|
|
int __read_mostly watchdog_user_enabled = 1;
|
2023-05-19 17:18:36 +00:00
|
|
|
static int __read_mostly watchdog_hardlockup_user_enabled = WATCHDOG_HARDLOCKUP_DEFAULT;
|
|
|
|
static int __read_mostly watchdog_softlockup_user_enabled = 1;
|
2017-09-12 19:37:15 +00:00
|
|
|
int __read_mostly watchdog_thresh = 10;
|
2023-05-19 17:18:36 +00:00
|
|
|
static int __read_mostly watchdog_hardlockup_available;
|
2017-09-12 19:37:15 +00:00
|
|
|
|
|
|
|
struct cpumask watchdog_cpumask __read_mostly;
|
|
|
|
unsigned long *watchdog_cpumask_bits = cpumask_bits(&watchdog_cpumask);
|
|
|
|
|
2017-07-12 21:35:46 +00:00
|
|
|
#ifdef CONFIG_HARDLOCKUP_DETECTOR
|
2020-06-08 04:40:42 +00:00
|
|
|
|
|
|
|
# ifdef CONFIG_SMP
|
|
|
|
int __read_mostly sysctl_hardlockup_all_cpu_backtrace;
|
|
|
|
# endif /* CONFIG_SMP */
|
|
|
|
|
2017-07-12 21:35:46 +00:00
|
|
|
/*
|
|
|
|
* Should we panic when a soft-lockup or hard-lockup occurs:
|
|
|
|
*/
|
|
|
|
unsigned int __read_mostly hardlockup_panic =
|
2022-04-29 21:38:00 +00:00
|
|
|
IS_ENABLED(CONFIG_BOOTPARAM_HARDLOCKUP_PANIC);
|
2017-07-12 21:35:46 +00:00
|
|
|
/*
|
|
|
|
* We may not want to enable hard lockup detection by default in all cases,
|
|
|
|
* for example when running the kernel as a guest on a hypervisor. In these
|
|
|
|
* cases this function can be called to disable hard lockup detection. This
|
|
|
|
* function should only be executed once by the boot processor before the
|
|
|
|
* kernel command line parameters are parsed, because otherwise it is not
|
|
|
|
* possible to override this in hardlockup_panic_setup().
|
|
|
|
*/
|
2017-09-12 19:37:02 +00:00
|
|
|
void __init hardlockup_detector_disable(void)
|
2017-07-12 21:35:46 +00:00
|
|
|
{
|
2023-05-19 17:18:36 +00:00
|
|
|
watchdog_hardlockup_user_enabled = 0;
|
2017-07-12 21:35:46 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int __init hardlockup_panic_setup(char *str)
|
|
|
|
{
|
|
|
|
if (!strncmp(str, "panic", 5))
|
|
|
|
hardlockup_panic = 1;
|
|
|
|
else if (!strncmp(str, "nopanic", 7))
|
|
|
|
hardlockup_panic = 0;
|
|
|
|
else if (!strncmp(str, "0", 1))
|
2023-05-19 17:18:36 +00:00
|
|
|
watchdog_hardlockup_user_enabled = 0;
|
2017-07-12 21:35:46 +00:00
|
|
|
else if (!strncmp(str, "1", 1))
|
2023-05-19 17:18:36 +00:00
|
|
|
watchdog_hardlockup_user_enabled = 1;
|
2017-07-12 21:35:46 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
__setup("nmi_watchdog=", hardlockup_panic_setup);
|
|
|
|
|
2017-09-12 19:37:07 +00:00
|
|
|
#endif /* CONFIG_HARDLOCKUP_DETECTOR */
|
2017-07-12 21:35:46 +00:00
|
|
|
|
watchdog/hardlockup: detect hard lockups using secondary (buddy) CPUs
Implement a hardlockup detector that doesn't doesn't need any extra
arch-specific support code to detect lockups. Instead of using something
arch-specific we will use the buddy system, where each CPU watches out for
another one. Specifically, each CPU will use its softlockup hrtimer to
check that the next CPU is processing hrtimer interrupts by verifying that
a counter is increasing.
NOTE: unlike the other hard lockup detectors, the buddy one can't easily
show what's happening on the CPU that locked up just by doing a simple
backtrace. It relies on some other mechanism in the system to get
information about the locked up CPUs. This could be support for NMI
backtraces like [1], it could be a mechanism for printing the PC of locked
CPUs at panic time like [2] / [3], or it could be something else. Even
though that means we still rely on arch-specific code, this arch-specific
code seems to often be implemented even on architectures that don't have a
hardlockup detector.
This style of hardlockup detector originated in some downstream Android
trees and has been rebased on / carried in ChromeOS trees for quite a long
time for use on arm and arm64 boards. Historically on these boards we've
leveraged mechanism [2] / [3] to get information about hung CPUs, but we
could move to [1].
Although the original motivation for the buddy system was for use on
systems without an arch-specific hardlockup detector, it can still be
useful to use even on systems that _do_ have an arch-specific hardlockup
detector. On x86, for instance, there is a 24-part patch series [4] in
progress switching the arch-specific hard lockup detector from a scarce
perf counter to a less-scarce hardware resource. Potentially the buddy
system could be a simpler alternative to free up the perf counter but
still get hard lockup detection.
Overall, pros (+) and cons (-) of the buddy system compared to an
arch-specific hardlockup detector (which might be implemented using
perf):
+ The buddy system is usable on systems that don't have an
arch-specific hardlockup detector, like arm32 and arm64 (though it's
being worked on for arm64 [5]).
+ The buddy system may free up scarce hardware resources.
+ If a CPU totally goes out to lunch (can't process NMIs) the buddy
system could still detect the problem (though it would be unlikely
to be able to get a stack trace).
+ The buddy system uses the same timer function to pet the hardlockup
detector on the running CPU as it uses to detect hardlockups on
other CPUs. Compared to other hardlockup detectors, this means it
generates fewer interrupts and thus is likely better able to let
CPUs stay idle longer.
- If all CPUs are hard locked up at the same time the buddy system
can't detect it.
- If we don't have SMP we can't use the buddy system.
- The buddy system needs an arch-specific mechanism (possibly NMI
backtrace) to get info about the locked up CPU.
[1] https://lore.kernel.org/r/20230419225604.21204-1-dianders@chromium.org
[2] https://issuetracker.google.com/172213129
[3] https://docs.kernel.org/trace/coresight/coresight-cpu-debug.html
[4] https://lore.kernel.org/lkml/20230301234753.28582-1-ricardo.neri-calderon@linux.intel.com/
[5] https://lore.kernel.org/linux-arm-kernel/20220903093415.15850-1-lecopzer.chen@mediatek.com/
Link: https://lkml.kernel.org/r/20230519101840.v5.14.I6bf789d21d0c3d75d382e7e51a804a7a51315f2c@changeid
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ian Rogers <irogers@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-05-19 17:18:38 +00:00
|
|
|
#if defined(CONFIG_HARDLOCKUP_DETECTOR_COUNTS_HRTIMER)
|
2023-05-19 17:18:32 +00:00
|
|
|
|
2023-05-19 17:18:34 +00:00
|
|
|
static DEFINE_PER_CPU(atomic_t, hrtimer_interrupts);
|
|
|
|
static DEFINE_PER_CPU(int, hrtimer_interrupts_saved);
|
2023-05-19 17:18:33 +00:00
|
|
|
static DEFINE_PER_CPU(bool, watchdog_hardlockup_warned);
|
2023-05-19 17:18:35 +00:00
|
|
|
static DEFINE_PER_CPU(bool, watchdog_hardlockup_touched);
|
2023-05-19 17:18:33 +00:00
|
|
|
static unsigned long watchdog_hardlockup_all_cpu_dumped;
|
2023-05-19 17:18:32 +00:00
|
|
|
|
2023-05-19 17:18:35 +00:00
|
|
|
notrace void arch_touch_nmi_watchdog(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Using __raw here because some code paths have
|
|
|
|
* preemption enabled. If preemption is enabled
|
|
|
|
* then interrupts should be enabled too, in which
|
|
|
|
* case we shouldn't have to worry about the watchdog
|
|
|
|
* going off.
|
|
|
|
*/
|
|
|
|
raw_cpu_write(watchdog_hardlockup_touched, true);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(arch_touch_nmi_watchdog);
|
|
|
|
|
watchdog/hardlockup: detect hard lockups using secondary (buddy) CPUs
Implement a hardlockup detector that doesn't doesn't need any extra
arch-specific support code to detect lockups. Instead of using something
arch-specific we will use the buddy system, where each CPU watches out for
another one. Specifically, each CPU will use its softlockup hrtimer to
check that the next CPU is processing hrtimer interrupts by verifying that
a counter is increasing.
NOTE: unlike the other hard lockup detectors, the buddy one can't easily
show what's happening on the CPU that locked up just by doing a simple
backtrace. It relies on some other mechanism in the system to get
information about the locked up CPUs. This could be support for NMI
backtraces like [1], it could be a mechanism for printing the PC of locked
CPUs at panic time like [2] / [3], or it could be something else. Even
though that means we still rely on arch-specific code, this arch-specific
code seems to often be implemented even on architectures that don't have a
hardlockup detector.
This style of hardlockup detector originated in some downstream Android
trees and has been rebased on / carried in ChromeOS trees for quite a long
time for use on arm and arm64 boards. Historically on these boards we've
leveraged mechanism [2] / [3] to get information about hung CPUs, but we
could move to [1].
Although the original motivation for the buddy system was for use on
systems without an arch-specific hardlockup detector, it can still be
useful to use even on systems that _do_ have an arch-specific hardlockup
detector. On x86, for instance, there is a 24-part patch series [4] in
progress switching the arch-specific hard lockup detector from a scarce
perf counter to a less-scarce hardware resource. Potentially the buddy
system could be a simpler alternative to free up the perf counter but
still get hard lockup detection.
Overall, pros (+) and cons (-) of the buddy system compared to an
arch-specific hardlockup detector (which might be implemented using
perf):
+ The buddy system is usable on systems that don't have an
arch-specific hardlockup detector, like arm32 and arm64 (though it's
being worked on for arm64 [5]).
+ The buddy system may free up scarce hardware resources.
+ If a CPU totally goes out to lunch (can't process NMIs) the buddy
system could still detect the problem (though it would be unlikely
to be able to get a stack trace).
+ The buddy system uses the same timer function to pet the hardlockup
detector on the running CPU as it uses to detect hardlockups on
other CPUs. Compared to other hardlockup detectors, this means it
generates fewer interrupts and thus is likely better able to let
CPUs stay idle longer.
- If all CPUs are hard locked up at the same time the buddy system
can't detect it.
- If we don't have SMP we can't use the buddy system.
- The buddy system needs an arch-specific mechanism (possibly NMI
backtrace) to get info about the locked up CPU.
[1] https://lore.kernel.org/r/20230419225604.21204-1-dianders@chromium.org
[2] https://issuetracker.google.com/172213129
[3] https://docs.kernel.org/trace/coresight/coresight-cpu-debug.html
[4] https://lore.kernel.org/lkml/20230301234753.28582-1-ricardo.neri-calderon@linux.intel.com/
[5] https://lore.kernel.org/linux-arm-kernel/20220903093415.15850-1-lecopzer.chen@mediatek.com/
Link: https://lkml.kernel.org/r/20230519101840.v5.14.I6bf789d21d0c3d75d382e7e51a804a7a51315f2c@changeid
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ian Rogers <irogers@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-05-19 17:18:38 +00:00
|
|
|
void watchdog_hardlockup_touch_cpu(unsigned int cpu)
|
|
|
|
{
|
|
|
|
per_cpu(watchdog_hardlockup_touched, cpu) = true;
|
|
|
|
|
|
|
|
/* Match with smp_rmb() in watchdog_hardlockup_check() */
|
|
|
|
smp_wmb();
|
|
|
|
}
|
|
|
|
|
2023-05-19 17:18:34 +00:00
|
|
|
static bool is_hardlockup(unsigned int cpu)
|
2023-05-19 17:18:32 +00:00
|
|
|
{
|
2023-05-19 17:18:34 +00:00
|
|
|
int hrint = atomic_read(&per_cpu(hrtimer_interrupts, cpu));
|
2023-05-19 17:18:32 +00:00
|
|
|
|
2023-05-19 17:18:34 +00:00
|
|
|
if (per_cpu(hrtimer_interrupts_saved, cpu) == hrint)
|
2023-05-19 17:18:32 +00:00
|
|
|
return true;
|
|
|
|
|
2023-05-19 17:18:34 +00:00
|
|
|
/*
|
|
|
|
* NOTE: we don't need any fancy atomic_t or READ_ONCE/WRITE_ONCE
|
|
|
|
* for hrtimer_interrupts_saved. hrtimer_interrupts_saved is
|
|
|
|
* written/read by a single CPU.
|
|
|
|
*/
|
|
|
|
per_cpu(hrtimer_interrupts_saved, cpu) = hrint;
|
2023-05-19 17:18:33 +00:00
|
|
|
|
2023-05-19 17:18:32 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
watchdog/hardlockup: detect hard lockups using secondary (buddy) CPUs
Implement a hardlockup detector that doesn't doesn't need any extra
arch-specific support code to detect lockups. Instead of using something
arch-specific we will use the buddy system, where each CPU watches out for
another one. Specifically, each CPU will use its softlockup hrtimer to
check that the next CPU is processing hrtimer interrupts by verifying that
a counter is increasing.
NOTE: unlike the other hard lockup detectors, the buddy one can't easily
show what's happening on the CPU that locked up just by doing a simple
backtrace. It relies on some other mechanism in the system to get
information about the locked up CPUs. This could be support for NMI
backtraces like [1], it could be a mechanism for printing the PC of locked
CPUs at panic time like [2] / [3], or it could be something else. Even
though that means we still rely on arch-specific code, this arch-specific
code seems to often be implemented even on architectures that don't have a
hardlockup detector.
This style of hardlockup detector originated in some downstream Android
trees and has been rebased on / carried in ChromeOS trees for quite a long
time for use on arm and arm64 boards. Historically on these boards we've
leveraged mechanism [2] / [3] to get information about hung CPUs, but we
could move to [1].
Although the original motivation for the buddy system was for use on
systems without an arch-specific hardlockup detector, it can still be
useful to use even on systems that _do_ have an arch-specific hardlockup
detector. On x86, for instance, there is a 24-part patch series [4] in
progress switching the arch-specific hard lockup detector from a scarce
perf counter to a less-scarce hardware resource. Potentially the buddy
system could be a simpler alternative to free up the perf counter but
still get hard lockup detection.
Overall, pros (+) and cons (-) of the buddy system compared to an
arch-specific hardlockup detector (which might be implemented using
perf):
+ The buddy system is usable on systems that don't have an
arch-specific hardlockup detector, like arm32 and arm64 (though it's
being worked on for arm64 [5]).
+ The buddy system may free up scarce hardware resources.
+ If a CPU totally goes out to lunch (can't process NMIs) the buddy
system could still detect the problem (though it would be unlikely
to be able to get a stack trace).
+ The buddy system uses the same timer function to pet the hardlockup
detector on the running CPU as it uses to detect hardlockups on
other CPUs. Compared to other hardlockup detectors, this means it
generates fewer interrupts and thus is likely better able to let
CPUs stay idle longer.
- If all CPUs are hard locked up at the same time the buddy system
can't detect it.
- If we don't have SMP we can't use the buddy system.
- The buddy system needs an arch-specific mechanism (possibly NMI
backtrace) to get info about the locked up CPU.
[1] https://lore.kernel.org/r/20230419225604.21204-1-dianders@chromium.org
[2] https://issuetracker.google.com/172213129
[3] https://docs.kernel.org/trace/coresight/coresight-cpu-debug.html
[4] https://lore.kernel.org/lkml/20230301234753.28582-1-ricardo.neri-calderon@linux.intel.com/
[5] https://lore.kernel.org/linux-arm-kernel/20220903093415.15850-1-lecopzer.chen@mediatek.com/
Link: https://lkml.kernel.org/r/20230519101840.v5.14.I6bf789d21d0c3d75d382e7e51a804a7a51315f2c@changeid
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ian Rogers <irogers@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-05-19 17:18:38 +00:00
|
|
|
static unsigned long watchdog_hardlockup_kick(void)
|
2023-05-19 17:18:32 +00:00
|
|
|
{
|
2023-05-27 01:41:33 +00:00
|
|
|
return atomic_inc_return(this_cpu_ptr(&hrtimer_interrupts));
|
2023-05-19 17:18:32 +00:00
|
|
|
}
|
|
|
|
|
2023-05-19 17:18:34 +00:00
|
|
|
void watchdog_hardlockup_check(unsigned int cpu, struct pt_regs *regs)
|
2023-05-19 17:18:32 +00:00
|
|
|
{
|
watchdog/hardlockup: detect hard lockups using secondary (buddy) CPUs
Implement a hardlockup detector that doesn't doesn't need any extra
arch-specific support code to detect lockups. Instead of using something
arch-specific we will use the buddy system, where each CPU watches out for
another one. Specifically, each CPU will use its softlockup hrtimer to
check that the next CPU is processing hrtimer interrupts by verifying that
a counter is increasing.
NOTE: unlike the other hard lockup detectors, the buddy one can't easily
show what's happening on the CPU that locked up just by doing a simple
backtrace. It relies on some other mechanism in the system to get
information about the locked up CPUs. This could be support for NMI
backtraces like [1], it could be a mechanism for printing the PC of locked
CPUs at panic time like [2] / [3], or it could be something else. Even
though that means we still rely on arch-specific code, this arch-specific
code seems to often be implemented even on architectures that don't have a
hardlockup detector.
This style of hardlockup detector originated in some downstream Android
trees and has been rebased on / carried in ChromeOS trees for quite a long
time for use on arm and arm64 boards. Historically on these boards we've
leveraged mechanism [2] / [3] to get information about hung CPUs, but we
could move to [1].
Although the original motivation for the buddy system was for use on
systems without an arch-specific hardlockup detector, it can still be
useful to use even on systems that _do_ have an arch-specific hardlockup
detector. On x86, for instance, there is a 24-part patch series [4] in
progress switching the arch-specific hard lockup detector from a scarce
perf counter to a less-scarce hardware resource. Potentially the buddy
system could be a simpler alternative to free up the perf counter but
still get hard lockup detection.
Overall, pros (+) and cons (-) of the buddy system compared to an
arch-specific hardlockup detector (which might be implemented using
perf):
+ The buddy system is usable on systems that don't have an
arch-specific hardlockup detector, like arm32 and arm64 (though it's
being worked on for arm64 [5]).
+ The buddy system may free up scarce hardware resources.
+ If a CPU totally goes out to lunch (can't process NMIs) the buddy
system could still detect the problem (though it would be unlikely
to be able to get a stack trace).
+ The buddy system uses the same timer function to pet the hardlockup
detector on the running CPU as it uses to detect hardlockups on
other CPUs. Compared to other hardlockup detectors, this means it
generates fewer interrupts and thus is likely better able to let
CPUs stay idle longer.
- If all CPUs are hard locked up at the same time the buddy system
can't detect it.
- If we don't have SMP we can't use the buddy system.
- The buddy system needs an arch-specific mechanism (possibly NMI
backtrace) to get info about the locked up CPU.
[1] https://lore.kernel.org/r/20230419225604.21204-1-dianders@chromium.org
[2] https://issuetracker.google.com/172213129
[3] https://docs.kernel.org/trace/coresight/coresight-cpu-debug.html
[4] https://lore.kernel.org/lkml/20230301234753.28582-1-ricardo.neri-calderon@linux.intel.com/
[5] https://lore.kernel.org/linux-arm-kernel/20220903093415.15850-1-lecopzer.chen@mediatek.com/
Link: https://lkml.kernel.org/r/20230519101840.v5.14.I6bf789d21d0c3d75d382e7e51a804a7a51315f2c@changeid
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ian Rogers <irogers@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-05-19 17:18:38 +00:00
|
|
|
/* Match with smp_wmb() in watchdog_hardlockup_touch_cpu() */
|
|
|
|
smp_rmb();
|
|
|
|
|
2023-05-19 17:18:35 +00:00
|
|
|
if (per_cpu(watchdog_hardlockup_touched, cpu)) {
|
|
|
|
per_cpu(watchdog_hardlockup_touched, cpu) = false;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2023-05-19 17:18:33 +00:00
|
|
|
/*
|
|
|
|
* Check for a hardlockup by making sure the CPU's timer
|
|
|
|
* interrupt is incrementing. The timer interrupt should have
|
|
|
|
* fired multiple times before we overflow'd. If it hasn't
|
2023-05-19 17:18:32 +00:00
|
|
|
* then this is a good indication the cpu is stuck
|
|
|
|
*/
|
2023-05-19 17:18:34 +00:00
|
|
|
if (is_hardlockup(cpu)) {
|
2023-05-19 17:18:33 +00:00
|
|
|
unsigned int this_cpu = smp_processor_id();
|
2023-05-19 17:18:34 +00:00
|
|
|
struct cpumask backtrace_mask = *cpu_online_mask;
|
2023-05-19 17:18:32 +00:00
|
|
|
|
2023-05-19 17:18:33 +00:00
|
|
|
/* Only print hardlockups once. */
|
2023-05-19 17:18:34 +00:00
|
|
|
if (per_cpu(watchdog_hardlockup_warned, cpu))
|
2023-05-19 17:18:32 +00:00
|
|
|
return;
|
|
|
|
|
2023-05-19 17:18:34 +00:00
|
|
|
pr_emerg("Watchdog detected hard LOCKUP on cpu %d\n", cpu);
|
2023-05-19 17:18:32 +00:00
|
|
|
print_modules();
|
|
|
|
print_irqtrace_events(current);
|
2023-05-19 17:18:34 +00:00
|
|
|
if (cpu == this_cpu) {
|
|
|
|
if (regs)
|
|
|
|
show_regs(regs);
|
|
|
|
else
|
|
|
|
dump_stack();
|
|
|
|
cpumask_clear_cpu(cpu, &backtrace_mask);
|
|
|
|
} else {
|
|
|
|
if (trigger_single_cpu_backtrace(cpu))
|
|
|
|
cpumask_clear_cpu(cpu, &backtrace_mask);
|
|
|
|
}
|
2023-05-19 17:18:32 +00:00
|
|
|
|
|
|
|
/*
|
2023-05-19 17:18:34 +00:00
|
|
|
* Perform multi-CPU dump only once to avoid multiple
|
|
|
|
* hardlockups generating interleaving traces
|
2023-05-19 17:18:32 +00:00
|
|
|
*/
|
|
|
|
if (sysctl_hardlockup_all_cpu_backtrace &&
|
2023-05-19 17:18:33 +00:00
|
|
|
!test_and_set_bit(0, &watchdog_hardlockup_all_cpu_dumped))
|
2023-05-19 17:18:34 +00:00
|
|
|
trigger_cpumask_backtrace(&backtrace_mask);
|
2023-05-19 17:18:32 +00:00
|
|
|
|
|
|
|
if (hardlockup_panic)
|
|
|
|
nmi_panic(regs, "Hard LOCKUP");
|
|
|
|
|
2023-05-19 17:18:34 +00:00
|
|
|
per_cpu(watchdog_hardlockup_warned, cpu) = true;
|
2023-05-19 17:18:33 +00:00
|
|
|
} else {
|
2023-05-19 17:18:34 +00:00
|
|
|
per_cpu(watchdog_hardlockup_warned, cpu) = false;
|
2023-05-19 17:18:32 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
watchdog/hardlockup: detect hard lockups using secondary (buddy) CPUs
Implement a hardlockup detector that doesn't doesn't need any extra
arch-specific support code to detect lockups. Instead of using something
arch-specific we will use the buddy system, where each CPU watches out for
another one. Specifically, each CPU will use its softlockup hrtimer to
check that the next CPU is processing hrtimer interrupts by verifying that
a counter is increasing.
NOTE: unlike the other hard lockup detectors, the buddy one can't easily
show what's happening on the CPU that locked up just by doing a simple
backtrace. It relies on some other mechanism in the system to get
information about the locked up CPUs. This could be support for NMI
backtraces like [1], it could be a mechanism for printing the PC of locked
CPUs at panic time like [2] / [3], or it could be something else. Even
though that means we still rely on arch-specific code, this arch-specific
code seems to often be implemented even on architectures that don't have a
hardlockup detector.
This style of hardlockup detector originated in some downstream Android
trees and has been rebased on / carried in ChromeOS trees for quite a long
time for use on arm and arm64 boards. Historically on these boards we've
leveraged mechanism [2] / [3] to get information about hung CPUs, but we
could move to [1].
Although the original motivation for the buddy system was for use on
systems without an arch-specific hardlockup detector, it can still be
useful to use even on systems that _do_ have an arch-specific hardlockup
detector. On x86, for instance, there is a 24-part patch series [4] in
progress switching the arch-specific hard lockup detector from a scarce
perf counter to a less-scarce hardware resource. Potentially the buddy
system could be a simpler alternative to free up the perf counter but
still get hard lockup detection.
Overall, pros (+) and cons (-) of the buddy system compared to an
arch-specific hardlockup detector (which might be implemented using
perf):
+ The buddy system is usable on systems that don't have an
arch-specific hardlockup detector, like arm32 and arm64 (though it's
being worked on for arm64 [5]).
+ The buddy system may free up scarce hardware resources.
+ If a CPU totally goes out to lunch (can't process NMIs) the buddy
system could still detect the problem (though it would be unlikely
to be able to get a stack trace).
+ The buddy system uses the same timer function to pet the hardlockup
detector on the running CPU as it uses to detect hardlockups on
other CPUs. Compared to other hardlockup detectors, this means it
generates fewer interrupts and thus is likely better able to let
CPUs stay idle longer.
- If all CPUs are hard locked up at the same time the buddy system
can't detect it.
- If we don't have SMP we can't use the buddy system.
- The buddy system needs an arch-specific mechanism (possibly NMI
backtrace) to get info about the locked up CPU.
[1] https://lore.kernel.org/r/20230419225604.21204-1-dianders@chromium.org
[2] https://issuetracker.google.com/172213129
[3] https://docs.kernel.org/trace/coresight/coresight-cpu-debug.html
[4] https://lore.kernel.org/lkml/20230301234753.28582-1-ricardo.neri-calderon@linux.intel.com/
[5] https://lore.kernel.org/linux-arm-kernel/20220903093415.15850-1-lecopzer.chen@mediatek.com/
Link: https://lkml.kernel.org/r/20230519101840.v5.14.I6bf789d21d0c3d75d382e7e51a804a7a51315f2c@changeid
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ian Rogers <irogers@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-05-19 17:18:38 +00:00
|
|
|
#else /* CONFIG_HARDLOCKUP_DETECTOR_COUNTS_HRTIMER */
|
2023-05-19 17:18:32 +00:00
|
|
|
|
watchdog/hardlockup: detect hard lockups using secondary (buddy) CPUs
Implement a hardlockup detector that doesn't doesn't need any extra
arch-specific support code to detect lockups. Instead of using something
arch-specific we will use the buddy system, where each CPU watches out for
another one. Specifically, each CPU will use its softlockup hrtimer to
check that the next CPU is processing hrtimer interrupts by verifying that
a counter is increasing.
NOTE: unlike the other hard lockup detectors, the buddy one can't easily
show what's happening on the CPU that locked up just by doing a simple
backtrace. It relies on some other mechanism in the system to get
information about the locked up CPUs. This could be support for NMI
backtraces like [1], it could be a mechanism for printing the PC of locked
CPUs at panic time like [2] / [3], or it could be something else. Even
though that means we still rely on arch-specific code, this arch-specific
code seems to often be implemented even on architectures that don't have a
hardlockup detector.
This style of hardlockup detector originated in some downstream Android
trees and has been rebased on / carried in ChromeOS trees for quite a long
time for use on arm and arm64 boards. Historically on these boards we've
leveraged mechanism [2] / [3] to get information about hung CPUs, but we
could move to [1].
Although the original motivation for the buddy system was for use on
systems without an arch-specific hardlockup detector, it can still be
useful to use even on systems that _do_ have an arch-specific hardlockup
detector. On x86, for instance, there is a 24-part patch series [4] in
progress switching the arch-specific hard lockup detector from a scarce
perf counter to a less-scarce hardware resource. Potentially the buddy
system could be a simpler alternative to free up the perf counter but
still get hard lockup detection.
Overall, pros (+) and cons (-) of the buddy system compared to an
arch-specific hardlockup detector (which might be implemented using
perf):
+ The buddy system is usable on systems that don't have an
arch-specific hardlockup detector, like arm32 and arm64 (though it's
being worked on for arm64 [5]).
+ The buddy system may free up scarce hardware resources.
+ If a CPU totally goes out to lunch (can't process NMIs) the buddy
system could still detect the problem (though it would be unlikely
to be able to get a stack trace).
+ The buddy system uses the same timer function to pet the hardlockup
detector on the running CPU as it uses to detect hardlockups on
other CPUs. Compared to other hardlockup detectors, this means it
generates fewer interrupts and thus is likely better able to let
CPUs stay idle longer.
- If all CPUs are hard locked up at the same time the buddy system
can't detect it.
- If we don't have SMP we can't use the buddy system.
- The buddy system needs an arch-specific mechanism (possibly NMI
backtrace) to get info about the locked up CPU.
[1] https://lore.kernel.org/r/20230419225604.21204-1-dianders@chromium.org
[2] https://issuetracker.google.com/172213129
[3] https://docs.kernel.org/trace/coresight/coresight-cpu-debug.html
[4] https://lore.kernel.org/lkml/20230301234753.28582-1-ricardo.neri-calderon@linux.intel.com/
[5] https://lore.kernel.org/linux-arm-kernel/20220903093415.15850-1-lecopzer.chen@mediatek.com/
Link: https://lkml.kernel.org/r/20230519101840.v5.14.I6bf789d21d0c3d75d382e7e51a804a7a51315f2c@changeid
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ian Rogers <irogers@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-05-19 17:18:38 +00:00
|
|
|
static inline unsigned long watchdog_hardlockup_kick(void) { return 0; }
|
2023-05-19 17:18:32 +00:00
|
|
|
|
watchdog/hardlockup: detect hard lockups using secondary (buddy) CPUs
Implement a hardlockup detector that doesn't doesn't need any extra
arch-specific support code to detect lockups. Instead of using something
arch-specific we will use the buddy system, where each CPU watches out for
another one. Specifically, each CPU will use its softlockup hrtimer to
check that the next CPU is processing hrtimer interrupts by verifying that
a counter is increasing.
NOTE: unlike the other hard lockup detectors, the buddy one can't easily
show what's happening on the CPU that locked up just by doing a simple
backtrace. It relies on some other mechanism in the system to get
information about the locked up CPUs. This could be support for NMI
backtraces like [1], it could be a mechanism for printing the PC of locked
CPUs at panic time like [2] / [3], or it could be something else. Even
though that means we still rely on arch-specific code, this arch-specific
code seems to often be implemented even on architectures that don't have a
hardlockup detector.
This style of hardlockup detector originated in some downstream Android
trees and has been rebased on / carried in ChromeOS trees for quite a long
time for use on arm and arm64 boards. Historically on these boards we've
leveraged mechanism [2] / [3] to get information about hung CPUs, but we
could move to [1].
Although the original motivation for the buddy system was for use on
systems without an arch-specific hardlockup detector, it can still be
useful to use even on systems that _do_ have an arch-specific hardlockup
detector. On x86, for instance, there is a 24-part patch series [4] in
progress switching the arch-specific hard lockup detector from a scarce
perf counter to a less-scarce hardware resource. Potentially the buddy
system could be a simpler alternative to free up the perf counter but
still get hard lockup detection.
Overall, pros (+) and cons (-) of the buddy system compared to an
arch-specific hardlockup detector (which might be implemented using
perf):
+ The buddy system is usable on systems that don't have an
arch-specific hardlockup detector, like arm32 and arm64 (though it's
being worked on for arm64 [5]).
+ The buddy system may free up scarce hardware resources.
+ If a CPU totally goes out to lunch (can't process NMIs) the buddy
system could still detect the problem (though it would be unlikely
to be able to get a stack trace).
+ The buddy system uses the same timer function to pet the hardlockup
detector on the running CPU as it uses to detect hardlockups on
other CPUs. Compared to other hardlockup detectors, this means it
generates fewer interrupts and thus is likely better able to let
CPUs stay idle longer.
- If all CPUs are hard locked up at the same time the buddy system
can't detect it.
- If we don't have SMP we can't use the buddy system.
- The buddy system needs an arch-specific mechanism (possibly NMI
backtrace) to get info about the locked up CPU.
[1] https://lore.kernel.org/r/20230419225604.21204-1-dianders@chromium.org
[2] https://issuetracker.google.com/172213129
[3] https://docs.kernel.org/trace/coresight/coresight-cpu-debug.html
[4] https://lore.kernel.org/lkml/20230301234753.28582-1-ricardo.neri-calderon@linux.intel.com/
[5] https://lore.kernel.org/linux-arm-kernel/20220903093415.15850-1-lecopzer.chen@mediatek.com/
Link: https://lkml.kernel.org/r/20230519101840.v5.14.I6bf789d21d0c3d75d382e7e51a804a7a51315f2c@changeid
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ian Rogers <irogers@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-05-19 17:18:38 +00:00
|
|
|
#endif /* !CONFIG_HARDLOCKUP_DETECTOR_COUNTS_HRTIMER */
|
2023-05-19 17:18:32 +00:00
|
|
|
|
2017-07-12 21:35:46 +00:00
|
|
|
/*
|
2023-05-19 17:18:37 +00:00
|
|
|
* These functions can be overridden based on the configured hardlockdup detector.
|
2017-07-12 21:35:49 +00:00
|
|
|
*
|
2023-05-19 17:18:36 +00:00
|
|
|
* watchdog_hardlockup_enable/disable can be implemented to start and stop when
|
2023-05-19 17:18:37 +00:00
|
|
|
* softlockup watchdog start and stop. The detector must select the
|
2017-07-12 21:35:49 +00:00
|
|
|
* SOFTLOCKUP_DETECTOR Kconfig.
|
2017-07-12 21:35:46 +00:00
|
|
|
*/
|
2023-05-19 17:18:37 +00:00
|
|
|
void __weak watchdog_hardlockup_enable(unsigned int cpu) { }
|
2017-09-12 19:37:04 +00:00
|
|
|
|
2023-05-19 17:18:37 +00:00
|
|
|
void __weak watchdog_hardlockup_disable(unsigned int cpu) { }
|
2017-07-12 21:35:46 +00:00
|
|
|
|
2023-05-19 17:18:40 +00:00
|
|
|
/*
|
|
|
|
* Watchdog-detector specific API.
|
|
|
|
*
|
|
|
|
* Return 0 when hardlockup watchdog is available, negative value otherwise.
|
|
|
|
* Note that the negative value means that a delayed probe might
|
|
|
|
* succeed later.
|
|
|
|
*/
|
2023-05-19 17:18:36 +00:00
|
|
|
int __weak __init watchdog_hardlockup_probe(void)
|
2017-09-12 19:37:19 +00:00
|
|
|
{
|
2023-05-19 17:18:37 +00:00
|
|
|
return -ENODEV;
|
2017-09-12 19:37:19 +00:00
|
|
|
}
|
|
|
|
|
2017-09-12 19:37:16 +00:00
|
|
|
/**
|
2023-05-19 17:18:36 +00:00
|
|
|
* watchdog_hardlockup_stop - Stop the watchdog for reconfiguration
|
2017-09-12 19:37:16 +00:00
|
|
|
*
|
2017-10-02 10:34:50 +00:00
|
|
|
* The reconfiguration steps are:
|
2023-05-19 17:18:36 +00:00
|
|
|
* watchdog_hardlockup_stop();
|
2017-09-12 19:37:16 +00:00
|
|
|
* update_variables();
|
2023-05-19 17:18:36 +00:00
|
|
|
* watchdog_hardlockup_start();
|
2017-10-02 10:34:50 +00:00
|
|
|
*/
|
2023-05-19 17:18:36 +00:00
|
|
|
void __weak watchdog_hardlockup_stop(void) { }
|
2017-10-02 10:34:50 +00:00
|
|
|
|
|
|
|
/**
|
2023-05-19 17:18:36 +00:00
|
|
|
* watchdog_hardlockup_start - Start the watchdog after reconfiguration
|
2017-09-12 19:37:16 +00:00
|
|
|
*
|
2023-05-19 17:18:36 +00:00
|
|
|
* Counterpart to watchdog_hardlockup_stop().
|
2017-10-02 10:34:50 +00:00
|
|
|
*
|
|
|
|
* The following variables have been updated in update_variables() and
|
|
|
|
* contain the currently valid configuration:
|
2017-09-12 19:37:15 +00:00
|
|
|
* - watchdog_enabled
|
2017-07-12 21:35:49 +00:00
|
|
|
* - watchdog_thresh
|
|
|
|
* - watchdog_cpumask
|
|
|
|
*/
|
2023-05-19 17:18:36 +00:00
|
|
|
void __weak watchdog_hardlockup_start(void) { }
|
2017-07-12 21:35:49 +00:00
|
|
|
|
2017-09-12 19:37:17 +00:00
|
|
|
/**
|
|
|
|
* lockup_detector_update_enable - Update the sysctl enable bit
|
|
|
|
*
|
2023-05-19 17:18:36 +00:00
|
|
|
* Caller needs to make sure that the hard watchdogs are off, so this
|
|
|
|
* can't race with watchdog_hardlockup_disable().
|
2017-09-12 19:37:17 +00:00
|
|
|
*/
|
|
|
|
static void lockup_detector_update_enable(void)
|
|
|
|
{
|
|
|
|
watchdog_enabled = 0;
|
|
|
|
if (!watchdog_user_enabled)
|
|
|
|
return;
|
2023-05-19 17:18:36 +00:00
|
|
|
if (watchdog_hardlockup_available && watchdog_hardlockup_user_enabled)
|
|
|
|
watchdog_enabled |= WATCHDOG_HARDLOCKUP_ENABLED;
|
|
|
|
if (watchdog_softlockup_user_enabled)
|
|
|
|
watchdog_enabled |= WATCHDOG_SOFTOCKUP_ENABLED;
|
2017-09-12 19:37:17 +00:00
|
|
|
}
|
|
|
|
|
2017-07-12 21:35:46 +00:00
|
|
|
#ifdef CONFIG_SOFTLOCKUP_DETECTOR
|
|
|
|
|
2021-04-30 05:54:26 +00:00
|
|
|
/*
|
|
|
|
* Delay the soflockup report when running a known slow code.
|
|
|
|
* It does _not_ affect the timestamp of the last successdul reschedule.
|
|
|
|
*/
|
|
|
|
#define SOFTLOCKUP_DELAY_REPORT ULONG_MAX
|
2020-01-16 18:17:02 +00:00
|
|
|
|
2020-06-08 04:40:42 +00:00
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
int __read_mostly sysctl_softlockup_all_cpu_backtrace;
|
|
|
|
#endif
|
|
|
|
|
2020-11-14 06:52:10 +00:00
|
|
|
static struct cpumask watchdog_allowed_mask __read_mostly;
|
|
|
|
|
2017-09-12 19:37:06 +00:00
|
|
|
/* Global variables, exported for sysctl */
|
|
|
|
unsigned int __read_mostly softlockup_panic =
|
2022-04-29 21:38:00 +00:00
|
|
|
IS_ENABLED(CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC);
|
2017-09-12 19:37:10 +00:00
|
|
|
|
2018-06-07 08:52:03 +00:00
|
|
|
static bool softlockup_initialized __read_mostly;
|
2012-12-17 23:59:50 +00:00
|
|
|
static u64 __read_mostly sample_period;
|
2010-05-07 21:11:44 +00:00
|
|
|
|
2021-04-30 05:54:26 +00:00
|
|
|
/* Timestamp taken after the last successful reschedule. */
|
2010-05-07 21:11:44 +00:00
|
|
|
static DEFINE_PER_CPU(unsigned long, watchdog_touch_ts);
|
2021-04-30 05:54:26 +00:00
|
|
|
/* Timestamp of the last softlockup report. */
|
|
|
|
static DEFINE_PER_CPU(unsigned long, watchdog_report_ts);
|
2010-05-07 21:11:44 +00:00
|
|
|
static DEFINE_PER_CPU(struct hrtimer, watchdog_hrtimer);
|
|
|
|
static DEFINE_PER_CPU(bool, softlockup_touch_sync);
|
2014-06-23 20:22:05 +00:00
|
|
|
static unsigned long soft_lockup_nmi_warn;
|
2010-05-07 21:11:44 +00:00
|
|
|
|
|
|
|
static int __init nowatchdog_setup(char *str)
|
|
|
|
{
|
2017-09-12 19:37:17 +00:00
|
|
|
watchdog_user_enabled = 0;
|
2010-05-07 21:11:44 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
__setup("nowatchdog", nowatchdog_setup);
|
|
|
|
|
|
|
|
static int __init nosoftlockup_setup(char *str)
|
|
|
|
{
|
2023-05-19 17:18:36 +00:00
|
|
|
watchdog_softlockup_user_enabled = 0;
|
2010-05-07 21:11:44 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
__setup("nosoftlockup", nosoftlockup_setup);
|
2015-04-14 22:44:13 +00:00
|
|
|
|
2018-11-01 13:30:18 +00:00
|
|
|
static int __init watchdog_thresh_setup(char *str)
|
|
|
|
{
|
|
|
|
get_option(&str, &watchdog_thresh);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
__setup("watchdog_thresh=", watchdog_thresh_setup);
|
|
|
|
|
2017-09-12 19:37:04 +00:00
|
|
|
static void __lockup_detector_cleanup(void);
|
|
|
|
|
2011-05-23 05:10:23 +00:00
|
|
|
/*
|
|
|
|
* Hard-lockup warnings should be triggered after just a few seconds. Soft-
|
|
|
|
* lockups can have false positives under extreme conditions. So we generally
|
|
|
|
* want a higher threshold for soft lockups than for hard lockups. So we couple
|
|
|
|
* the thresholds with a factor: we make the soft threshold twice the amount of
|
|
|
|
* time the hard threshold is.
|
|
|
|
*/
|
2011-05-24 03:43:18 +00:00
|
|
|
static int get_softlockup_thresh(void)
|
2011-05-23 05:10:23 +00:00
|
|
|
{
|
|
|
|
return watchdog_thresh * 2;
|
|
|
|
}
|
2010-05-07 21:11:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Returns seconds, approximately. We don't need nanosecond
|
|
|
|
* resolution, and we don't need to waste time with a big divide when
|
|
|
|
* 2^30ns == 1.074s.
|
|
|
|
*/
|
2012-12-27 02:49:44 +00:00
|
|
|
static unsigned long get_timestamp(void)
|
2010-05-07 21:11:44 +00:00
|
|
|
{
|
2015-02-12 23:01:24 +00:00
|
|
|
return running_clock() >> 30LL; /* 2^30 ~= 10^9 */
|
2010-05-07 21:11:44 +00:00
|
|
|
}
|
|
|
|
|
2012-12-17 23:59:50 +00:00
|
|
|
static void set_sample_period(void)
|
2010-05-07 21:11:44 +00:00
|
|
|
{
|
|
|
|
/*
|
2011-05-23 05:10:22 +00:00
|
|
|
* convert watchdog_thresh from seconds to ns
|
2012-02-09 22:42:22 +00:00
|
|
|
* the divide by 5 is to give hrtimer several chances (two
|
|
|
|
* or three with the current relation between the soft
|
|
|
|
* and hard thresholds) to increment before the
|
|
|
|
* hardlockup detector generates a warning
|
2010-05-07 21:11:44 +00:00
|
|
|
*/
|
2012-12-17 23:59:50 +00:00
|
|
|
sample_period = get_softlockup_thresh() * ((u64)NSEC_PER_SEC / 5);
|
2017-08-15 07:50:13 +00:00
|
|
|
watchdog_update_hrtimer_threshold(sample_period);
|
2010-05-07 21:11:44 +00:00
|
|
|
}
|
|
|
|
|
2021-04-30 05:54:26 +00:00
|
|
|
static void update_report_ts(void)
|
|
|
|
{
|
|
|
|
__this_cpu_write(watchdog_report_ts, get_timestamp());
|
|
|
|
}
|
|
|
|
|
2010-05-07 21:11:44 +00:00
|
|
|
/* Commands for resetting the watchdog */
|
2021-04-30 05:54:20 +00:00
|
|
|
static void update_touch_ts(void)
|
2010-05-07 21:11:44 +00:00
|
|
|
{
|
2012-12-27 02:49:44 +00:00
|
|
|
__this_cpu_write(watchdog_touch_ts, get_timestamp());
|
2021-04-30 05:54:26 +00:00
|
|
|
update_report_ts();
|
2010-05-07 21:11:44 +00:00
|
|
|
}
|
|
|
|
|
2015-12-08 16:28:04 +00:00
|
|
|
/**
|
|
|
|
* touch_softlockup_watchdog_sched - touch watchdog on scheduler stalls
|
|
|
|
*
|
|
|
|
* Call when the scheduler may have stalled for legitimate reasons
|
|
|
|
* preventing the watchdog task from executing - e.g. the scheduler
|
|
|
|
* entering idle state. This should only be used for scheduler events.
|
|
|
|
* Use touch_softlockup_watchdog() for everything else.
|
|
|
|
*/
|
2018-08-21 15:25:07 +00:00
|
|
|
notrace void touch_softlockup_watchdog_sched(void)
|
2010-05-07 21:11:44 +00:00
|
|
|
{
|
2014-04-18 22:07:12 +00:00
|
|
|
/*
|
2021-04-30 05:54:26 +00:00
|
|
|
* Preemption can be enabled. It doesn't matter which CPU's watchdog
|
|
|
|
* report period gets restarted here, so use the raw_ operation.
|
2014-04-18 22:07:12 +00:00
|
|
|
*/
|
2021-04-30 05:54:26 +00:00
|
|
|
raw_cpu_write(watchdog_report_ts, SOFTLOCKUP_DELAY_REPORT);
|
2010-05-07 21:11:44 +00:00
|
|
|
}
|
2015-12-08 16:28:04 +00:00
|
|
|
|
2018-08-21 15:25:07 +00:00
|
|
|
notrace void touch_softlockup_watchdog(void)
|
2015-12-08 16:28:04 +00:00
|
|
|
{
|
|
|
|
touch_softlockup_watchdog_sched();
|
workqueue: implement lockup detector
Workqueue stalls can happen from a variety of usage bugs such as
missing WQ_MEM_RECLAIM flag or concurrency managed work item
indefinitely staying RUNNING. These stalls can be extremely difficult
to hunt down because the usual warning mechanisms can't detect
workqueue stalls and the internal state is pretty opaque.
To alleviate the situation, this patch implements workqueue lockup
detector. It periodically monitors all worker_pools periodically and,
if any pool failed to make forward progress longer than the threshold
duration, triggers warning and dumps workqueue state as follows.
BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 31s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x0
pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=17/256
pending: monkey_wrench_fn, e1000_watchdog, cache_reap, vmstat_shepherd, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, cgroup_release_agent
workqueue events_power_efficient: flags=0x80
pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
pending: check_lifetime, neigh_periodic_work
workqueue cgroup_pidlist_destroy: flags=0x0
pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/1
pending: cgroup_pidlist_destroy_work_fn
...
The detection mechanism is controller through kernel parameter
workqueue.watchdog_thresh and can be updated at runtime through the
sysfs module parameter file.
v2: Decoupled from softlockup control knobs.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Don Zickus <dzickus@redhat.com>
Cc: Ulrich Obergfell <uobergfe@redhat.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Chris Mason <clm@fb.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
2015-12-08 16:28:04 +00:00
|
|
|
wq_watchdog_touch(raw_smp_processor_id());
|
2015-12-08 16:28:04 +00:00
|
|
|
}
|
2010-05-13 06:53:33 +00:00
|
|
|
EXPORT_SYMBOL(touch_softlockup_watchdog);
|
2010-05-07 21:11:44 +00:00
|
|
|
|
2010-05-07 21:11:45 +00:00
|
|
|
void touch_all_softlockup_watchdogs(void)
|
2010-05-07 21:11:44 +00:00
|
|
|
{
|
|
|
|
int cpu;
|
|
|
|
|
|
|
|
/*
|
2017-09-12 19:37:11 +00:00
|
|
|
* watchdog_mutex cannpt be taken here, as this might be called
|
|
|
|
* from (soft)interrupt context, so the access to
|
|
|
|
* watchdog_allowed_cpumask might race with a concurrent update.
|
|
|
|
*
|
|
|
|
* The watchdog time stamp can race against a concurrent real
|
|
|
|
* update as well, the only side effect might be a cycle delay for
|
|
|
|
* the softlockup check.
|
2010-05-07 21:11:44 +00:00
|
|
|
*/
|
2021-03-24 11:40:29 +00:00
|
|
|
for_each_cpu(cpu, &watchdog_allowed_mask) {
|
2021-04-30 05:54:26 +00:00
|
|
|
per_cpu(watchdog_report_ts, cpu) = SOFTLOCKUP_DELAY_REPORT;
|
2021-03-24 11:40:29 +00:00
|
|
|
wq_watchdog_touch(cpu);
|
|
|
|
}
|
2010-05-07 21:11:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void touch_softlockup_watchdog_sync(void)
|
|
|
|
{
|
2014-08-17 17:30:34 +00:00
|
|
|
__this_cpu_write(softlockup_touch_sync, true);
|
2021-04-30 05:54:26 +00:00
|
|
|
__this_cpu_write(watchdog_report_ts, SOFTLOCKUP_DELAY_REPORT);
|
2010-05-07 21:11:44 +00:00
|
|
|
}
|
|
|
|
|
2021-05-23 00:41:59 +00:00
|
|
|
static int is_softlockup(unsigned long touch_ts,
|
|
|
|
unsigned long period_ts,
|
|
|
|
unsigned long now)
|
2010-05-07 21:11:44 +00:00
|
|
|
{
|
2023-05-19 17:18:36 +00:00
|
|
|
if ((watchdog_enabled & WATCHDOG_SOFTOCKUP_ENABLED) && watchdog_thresh) {
|
2015-04-14 22:44:13 +00:00
|
|
|
/* Warn about unreasonable delays. */
|
2021-04-30 05:54:26 +00:00
|
|
|
if (time_after(now, period_ts + get_softlockup_thresh()))
|
2015-04-14 22:44:13 +00:00
|
|
|
return now - touch_ts;
|
|
|
|
}
|
2010-05-07 21:11:44 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-07-12 21:35:46 +00:00
|
|
|
/* watchdog detector functions */
|
2018-07-13 10:42:08 +00:00
|
|
|
static DEFINE_PER_CPU(struct completion, softlockup_completion);
|
|
|
|
static DEFINE_PER_CPU(struct cpu_stop_work, softlockup_stop_work);
|
|
|
|
|
2018-06-07 08:52:03 +00:00
|
|
|
/*
|
2021-06-29 02:34:17 +00:00
|
|
|
* The watchdog feed function - touches the timestamp.
|
2018-06-07 08:52:03 +00:00
|
|
|
*
|
|
|
|
* It only runs once every sample_period seconds (4 seconds by
|
|
|
|
* default) to reset the softlockup timestamp. If this gets delayed
|
|
|
|
* for more than 2*watchdog_thresh seconds then the debug-printout
|
|
|
|
* triggers in watchdog_timer_fn().
|
|
|
|
*/
|
|
|
|
static int softlockup_fn(void *data)
|
|
|
|
{
|
2021-04-30 05:54:20 +00:00
|
|
|
update_touch_ts();
|
2018-07-13 10:42:08 +00:00
|
|
|
complete(this_cpu_ptr(&softlockup_completion));
|
2018-06-07 08:52:03 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-05-07 21:11:44 +00:00
|
|
|
/* watchdog kicker functions */
|
|
|
|
static enum hrtimer_restart watchdog_timer_fn(struct hrtimer *hrtimer)
|
|
|
|
{
|
2021-05-23 00:41:59 +00:00
|
|
|
unsigned long touch_ts, period_ts, now;
|
2010-05-07 21:11:44 +00:00
|
|
|
struct pt_regs *regs = get_irq_regs();
|
|
|
|
int duration;
|
2014-06-23 20:22:05 +00:00
|
|
|
int softlockup_all_cpu_backtrace = sysctl_softlockup_all_cpu_backtrace;
|
watchdog/hardlockup: detect hard lockups using secondary (buddy) CPUs
Implement a hardlockup detector that doesn't doesn't need any extra
arch-specific support code to detect lockups. Instead of using something
arch-specific we will use the buddy system, where each CPU watches out for
another one. Specifically, each CPU will use its softlockup hrtimer to
check that the next CPU is processing hrtimer interrupts by verifying that
a counter is increasing.
NOTE: unlike the other hard lockup detectors, the buddy one can't easily
show what's happening on the CPU that locked up just by doing a simple
backtrace. It relies on some other mechanism in the system to get
information about the locked up CPUs. This could be support for NMI
backtraces like [1], it could be a mechanism for printing the PC of locked
CPUs at panic time like [2] / [3], or it could be something else. Even
though that means we still rely on arch-specific code, this arch-specific
code seems to often be implemented even on architectures that don't have a
hardlockup detector.
This style of hardlockup detector originated in some downstream Android
trees and has been rebased on / carried in ChromeOS trees for quite a long
time for use on arm and arm64 boards. Historically on these boards we've
leveraged mechanism [2] / [3] to get information about hung CPUs, but we
could move to [1].
Although the original motivation for the buddy system was for use on
systems without an arch-specific hardlockup detector, it can still be
useful to use even on systems that _do_ have an arch-specific hardlockup
detector. On x86, for instance, there is a 24-part patch series [4] in
progress switching the arch-specific hard lockup detector from a scarce
perf counter to a less-scarce hardware resource. Potentially the buddy
system could be a simpler alternative to free up the perf counter but
still get hard lockup detection.
Overall, pros (+) and cons (-) of the buddy system compared to an
arch-specific hardlockup detector (which might be implemented using
perf):
+ The buddy system is usable on systems that don't have an
arch-specific hardlockup detector, like arm32 and arm64 (though it's
being worked on for arm64 [5]).
+ The buddy system may free up scarce hardware resources.
+ If a CPU totally goes out to lunch (can't process NMIs) the buddy
system could still detect the problem (though it would be unlikely
to be able to get a stack trace).
+ The buddy system uses the same timer function to pet the hardlockup
detector on the running CPU as it uses to detect hardlockups on
other CPUs. Compared to other hardlockup detectors, this means it
generates fewer interrupts and thus is likely better able to let
CPUs stay idle longer.
- If all CPUs are hard locked up at the same time the buddy system
can't detect it.
- If we don't have SMP we can't use the buddy system.
- The buddy system needs an arch-specific mechanism (possibly NMI
backtrace) to get info about the locked up CPU.
[1] https://lore.kernel.org/r/20230419225604.21204-1-dianders@chromium.org
[2] https://issuetracker.google.com/172213129
[3] https://docs.kernel.org/trace/coresight/coresight-cpu-debug.html
[4] https://lore.kernel.org/lkml/20230301234753.28582-1-ricardo.neri-calderon@linux.intel.com/
[5] https://lore.kernel.org/linux-arm-kernel/20220903093415.15850-1-lecopzer.chen@mediatek.com/
Link: https://lkml.kernel.org/r/20230519101840.v5.14.I6bf789d21d0c3d75d382e7e51a804a7a51315f2c@changeid
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ian Rogers <irogers@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-05-19 17:18:38 +00:00
|
|
|
unsigned long hrtimer_interrupts;
|
2010-05-07 21:11:44 +00:00
|
|
|
|
2017-09-12 19:37:05 +00:00
|
|
|
if (!watchdog_enabled)
|
2017-01-24 23:17:53 +00:00
|
|
|
return HRTIMER_NORESTART;
|
|
|
|
|
watchdog/hardlockup: detect hard lockups using secondary (buddy) CPUs
Implement a hardlockup detector that doesn't doesn't need any extra
arch-specific support code to detect lockups. Instead of using something
arch-specific we will use the buddy system, where each CPU watches out for
another one. Specifically, each CPU will use its softlockup hrtimer to
check that the next CPU is processing hrtimer interrupts by verifying that
a counter is increasing.
NOTE: unlike the other hard lockup detectors, the buddy one can't easily
show what's happening on the CPU that locked up just by doing a simple
backtrace. It relies on some other mechanism in the system to get
information about the locked up CPUs. This could be support for NMI
backtraces like [1], it could be a mechanism for printing the PC of locked
CPUs at panic time like [2] / [3], or it could be something else. Even
though that means we still rely on arch-specific code, this arch-specific
code seems to often be implemented even on architectures that don't have a
hardlockup detector.
This style of hardlockup detector originated in some downstream Android
trees and has been rebased on / carried in ChromeOS trees for quite a long
time for use on arm and arm64 boards. Historically on these boards we've
leveraged mechanism [2] / [3] to get information about hung CPUs, but we
could move to [1].
Although the original motivation for the buddy system was for use on
systems without an arch-specific hardlockup detector, it can still be
useful to use even on systems that _do_ have an arch-specific hardlockup
detector. On x86, for instance, there is a 24-part patch series [4] in
progress switching the arch-specific hard lockup detector from a scarce
perf counter to a less-scarce hardware resource. Potentially the buddy
system could be a simpler alternative to free up the perf counter but
still get hard lockup detection.
Overall, pros (+) and cons (-) of the buddy system compared to an
arch-specific hardlockup detector (which might be implemented using
perf):
+ The buddy system is usable on systems that don't have an
arch-specific hardlockup detector, like arm32 and arm64 (though it's
being worked on for arm64 [5]).
+ The buddy system may free up scarce hardware resources.
+ If a CPU totally goes out to lunch (can't process NMIs) the buddy
system could still detect the problem (though it would be unlikely
to be able to get a stack trace).
+ The buddy system uses the same timer function to pet the hardlockup
detector on the running CPU as it uses to detect hardlockups on
other CPUs. Compared to other hardlockup detectors, this means it
generates fewer interrupts and thus is likely better able to let
CPUs stay idle longer.
- If all CPUs are hard locked up at the same time the buddy system
can't detect it.
- If we don't have SMP we can't use the buddy system.
- The buddy system needs an arch-specific mechanism (possibly NMI
backtrace) to get info about the locked up CPU.
[1] https://lore.kernel.org/r/20230419225604.21204-1-dianders@chromium.org
[2] https://issuetracker.google.com/172213129
[3] https://docs.kernel.org/trace/coresight/coresight-cpu-debug.html
[4] https://lore.kernel.org/lkml/20230301234753.28582-1-ricardo.neri-calderon@linux.intel.com/
[5] https://lore.kernel.org/linux-arm-kernel/20220903093415.15850-1-lecopzer.chen@mediatek.com/
Link: https://lkml.kernel.org/r/20230519101840.v5.14.I6bf789d21d0c3d75d382e7e51a804a7a51315f2c@changeid
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ian Rogers <irogers@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-05-19 17:18:38 +00:00
|
|
|
hrtimer_interrupts = watchdog_hardlockup_kick();
|
|
|
|
|
|
|
|
/* test for hardlockups */
|
|
|
|
watchdog_buddy_check_hardlockup(hrtimer_interrupts);
|
2010-05-07 21:11:44 +00:00
|
|
|
|
|
|
|
/* kick the softlockup detector */
|
2018-07-13 10:42:08 +00:00
|
|
|
if (completion_done(this_cpu_ptr(&softlockup_completion))) {
|
|
|
|
reinit_completion(this_cpu_ptr(&softlockup_completion));
|
|
|
|
stop_one_cpu_nowait(smp_processor_id(),
|
|
|
|
softlockup_fn, NULL,
|
|
|
|
this_cpu_ptr(&softlockup_stop_work));
|
|
|
|
}
|
2010-05-07 21:11:44 +00:00
|
|
|
|
|
|
|
/* .. and repeat */
|
2012-12-17 23:59:50 +00:00
|
|
|
hrtimer_forward_now(hrtimer, ns_to_ktime(sample_period));
|
2010-05-07 21:11:44 +00:00
|
|
|
|
2021-05-23 00:41:59 +00:00
|
|
|
/*
|
|
|
|
* Read the current timestamp first. It might become invalid anytime
|
|
|
|
* when a virtual machine is stopped by the host or when the watchog
|
|
|
|
* is touched from NMI.
|
|
|
|
*/
|
|
|
|
now = get_timestamp();
|
2021-04-30 05:54:36 +00:00
|
|
|
/*
|
|
|
|
* If a virtual machine is stopped by the host it can look to
|
2021-05-23 00:41:59 +00:00
|
|
|
* the watchdog like a soft lockup. This function touches the watchdog.
|
2021-04-30 05:54:36 +00:00
|
|
|
*/
|
|
|
|
kvm_check_and_clear_guest_paused();
|
2021-05-23 00:41:59 +00:00
|
|
|
/*
|
|
|
|
* The stored timestamp is comparable with @now only when not touched.
|
|
|
|
* It might get touched anytime from NMI. Make sure that is_softlockup()
|
|
|
|
* uses the same (valid) value.
|
|
|
|
*/
|
|
|
|
period_ts = READ_ONCE(*this_cpu_ptr(&watchdog_report_ts));
|
2021-04-30 05:54:36 +00:00
|
|
|
|
|
|
|
/* Reset the interval when touched by known problematic code. */
|
2021-04-30 05:54:26 +00:00
|
|
|
if (period_ts == SOFTLOCKUP_DELAY_REPORT) {
|
2010-12-08 15:22:55 +00:00
|
|
|
if (unlikely(__this_cpu_read(softlockup_touch_sync))) {
|
2010-05-07 21:11:44 +00:00
|
|
|
/*
|
|
|
|
* If the time stamp was touched atomically
|
|
|
|
* make sure the scheduler tick is up to date.
|
|
|
|
*/
|
2010-12-08 15:22:55 +00:00
|
|
|
__this_cpu_write(softlockup_touch_sync, false);
|
2010-05-07 21:11:44 +00:00
|
|
|
sched_clock_tick();
|
|
|
|
}
|
2012-03-10 19:37:28 +00:00
|
|
|
|
2021-04-30 05:54:26 +00:00
|
|
|
update_report_ts();
|
2010-05-07 21:11:44 +00:00
|
|
|
return HRTIMER_RESTART;
|
|
|
|
}
|
|
|
|
|
2021-05-23 00:41:59 +00:00
|
|
|
/* Check for a softlockup. */
|
|
|
|
touch_ts = __this_cpu_read(watchdog_touch_ts);
|
|
|
|
duration = is_softlockup(touch_ts, period_ts, now);
|
2010-05-07 21:11:44 +00:00
|
|
|
if (unlikely(duration)) {
|
2021-04-30 05:54:33 +00:00
|
|
|
/*
|
|
|
|
* Prevent multiple soft-lockup reports if one cpu is already
|
|
|
|
* engaged in dumping all cpu back traces.
|
|
|
|
*/
|
2014-06-23 20:22:05 +00:00
|
|
|
if (softlockup_all_cpu_backtrace) {
|
2021-04-30 05:54:33 +00:00
|
|
|
if (test_and_set_bit_lock(0, &soft_lockup_nmi_warn))
|
2014-06-23 20:22:05 +00:00
|
|
|
return HRTIMER_RESTART;
|
|
|
|
}
|
|
|
|
|
2021-04-30 05:54:23 +00:00
|
|
|
/* Start period for the next softlockup warning. */
|
2021-04-30 05:54:26 +00:00
|
|
|
update_report_ts();
|
2021-04-30 05:54:23 +00:00
|
|
|
|
2014-08-06 23:04:03 +00:00
|
|
|
pr_emerg("BUG: soft lockup - CPU#%d stuck for %us! [%s:%d]\n",
|
2010-05-17 22:06:04 +00:00
|
|
|
smp_processor_id(), duration,
|
2010-05-07 21:11:44 +00:00
|
|
|
current->comm, task_pid_nr(current));
|
|
|
|
print_modules();
|
|
|
|
print_irqtrace_events(current);
|
|
|
|
if (regs)
|
|
|
|
show_regs(regs);
|
|
|
|
else
|
|
|
|
dump_stack();
|
|
|
|
|
2014-06-23 20:22:05 +00:00
|
|
|
if (softlockup_all_cpu_backtrace) {
|
|
|
|
trigger_allbutself_cpu_backtrace();
|
2021-04-30 05:54:33 +00:00
|
|
|
clear_bit_unlock(0, &soft_lockup_nmi_warn);
|
2014-06-23 20:22:05 +00:00
|
|
|
}
|
|
|
|
|
2014-08-08 21:22:31 +00:00
|
|
|
add_taint(TAINT_SOFTLOCKUP, LOCKDEP_STILL_OK);
|
2010-05-07 21:11:44 +00:00
|
|
|
if (softlockup_panic)
|
|
|
|
panic("softlockup: hung tasks");
|
2021-04-30 05:54:30 +00:00
|
|
|
}
|
2010-05-07 21:11:44 +00:00
|
|
|
|
|
|
|
return HRTIMER_RESTART;
|
|
|
|
}
|
|
|
|
|
2012-07-16 10:42:38 +00:00
|
|
|
static void watchdog_enable(unsigned int cpu)
|
2010-05-07 21:11:44 +00:00
|
|
|
{
|
2017-09-12 19:37:05 +00:00
|
|
|
struct hrtimer *hrtimer = this_cpu_ptr(&watchdog_hrtimer);
|
2018-07-13 10:42:08 +00:00
|
|
|
struct completion *done = this_cpu_ptr(&softlockup_completion);
|
2010-05-07 21:11:44 +00:00
|
|
|
|
2018-06-07 08:52:03 +00:00
|
|
|
WARN_ON_ONCE(cpu != smp_processor_id());
|
|
|
|
|
2018-07-13 10:42:08 +00:00
|
|
|
init_completion(done);
|
|
|
|
complete(done);
|
|
|
|
|
2017-09-12 19:37:05 +00:00
|
|
|
/*
|
2023-05-19 17:18:36 +00:00
|
|
|
* Start the timer first to prevent the hardlockup watchdog triggering
|
2017-09-12 19:37:05 +00:00
|
|
|
* before the timer has a chance to fire.
|
|
|
|
*/
|
2019-07-26 18:30:54 +00:00
|
|
|
hrtimer_init(hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL_HARD);
|
2012-12-19 19:51:31 +00:00
|
|
|
hrtimer->function = watchdog_timer_fn;
|
2017-09-12 19:37:05 +00:00
|
|
|
hrtimer_start(hrtimer, ns_to_ktime(sample_period),
|
2019-07-26 18:30:54 +00:00
|
|
|
HRTIMER_MODE_REL_PINNED_HARD);
|
2012-12-19 19:51:31 +00:00
|
|
|
|
2017-09-12 19:37:05 +00:00
|
|
|
/* Initialize timestamp */
|
2021-04-30 05:54:20 +00:00
|
|
|
update_touch_ts();
|
2023-05-19 17:18:36 +00:00
|
|
|
/* Enable the hardlockup detector */
|
|
|
|
if (watchdog_enabled & WATCHDOG_HARDLOCKUP_ENABLED)
|
|
|
|
watchdog_hardlockup_enable(cpu);
|
2012-07-16 10:42:38 +00:00
|
|
|
}
|
2010-05-07 21:11:44 +00:00
|
|
|
|
2012-07-16 10:42:38 +00:00
|
|
|
static void watchdog_disable(unsigned int cpu)
|
|
|
|
{
|
2017-09-12 19:37:05 +00:00
|
|
|
struct hrtimer *hrtimer = this_cpu_ptr(&watchdog_hrtimer);
|
2010-05-07 21:11:44 +00:00
|
|
|
|
2018-06-07 08:52:03 +00:00
|
|
|
WARN_ON_ONCE(cpu != smp_processor_id());
|
|
|
|
|
2017-09-12 19:37:05 +00:00
|
|
|
/*
|
2023-05-19 17:18:36 +00:00
|
|
|
* Disable the hardlockup detector first. That prevents that a large
|
|
|
|
* delay between disabling the timer and disabling the hardlockup
|
|
|
|
* detector causes a false positive.
|
2017-09-12 19:37:05 +00:00
|
|
|
*/
|
2023-05-19 17:18:36 +00:00
|
|
|
watchdog_hardlockup_disable(cpu);
|
2017-09-12 19:37:05 +00:00
|
|
|
hrtimer_cancel(hrtimer);
|
2018-07-13 10:42:08 +00:00
|
|
|
wait_for_completion(this_cpu_ptr(&softlockup_completion));
|
2010-05-07 21:11:44 +00:00
|
|
|
}
|
|
|
|
|
2018-06-07 08:52:03 +00:00
|
|
|
static int softlockup_stop_fn(void *data)
|
2013-06-06 13:42:53 +00:00
|
|
|
{
|
2018-06-07 08:52:03 +00:00
|
|
|
watchdog_disable(smp_processor_id());
|
|
|
|
return 0;
|
2013-06-06 13:42:53 +00:00
|
|
|
}
|
|
|
|
|
2018-06-07 08:52:03 +00:00
|
|
|
static void softlockup_stop_all(void)
|
2012-07-16 10:42:38 +00:00
|
|
|
{
|
2018-06-07 08:52:03 +00:00
|
|
|
int cpu;
|
|
|
|
|
|
|
|
if (!softlockup_initialized)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for_each_cpu(cpu, &watchdog_allowed_mask)
|
|
|
|
smp_call_on_cpu(cpu, softlockup_stop_fn, NULL, false);
|
|
|
|
|
|
|
|
cpumask_clear(&watchdog_allowed_mask);
|
2012-07-16 10:42:38 +00:00
|
|
|
}
|
|
|
|
|
2018-06-07 08:52:03 +00:00
|
|
|
static int softlockup_start_fn(void *data)
|
2012-07-16 10:42:38 +00:00
|
|
|
{
|
2018-06-07 08:52:03 +00:00
|
|
|
watchdog_enable(smp_processor_id());
|
|
|
|
return 0;
|
2012-07-16 10:42:38 +00:00
|
|
|
}
|
2010-05-07 21:11:44 +00:00
|
|
|
|
2018-06-07 08:52:03 +00:00
|
|
|
static void softlockup_start_all(void)
|
2017-09-12 19:37:10 +00:00
|
|
|
{
|
2018-06-07 08:52:03 +00:00
|
|
|
int cpu;
|
2017-09-12 19:37:10 +00:00
|
|
|
|
2018-06-07 08:52:03 +00:00
|
|
|
cpumask_copy(&watchdog_allowed_mask, &watchdog_cpumask);
|
|
|
|
for_each_cpu(cpu, &watchdog_allowed_mask)
|
|
|
|
smp_call_on_cpu(cpu, softlockup_start_fn, NULL, false);
|
2017-09-12 19:37:10 +00:00
|
|
|
}
|
|
|
|
|
2018-06-07 08:52:03 +00:00
|
|
|
int lockup_detector_online_cpu(unsigned int cpu)
|
2017-09-12 19:37:10 +00:00
|
|
|
{
|
2019-03-26 21:51:02 +00:00
|
|
|
if (cpumask_test_cpu(cpu, &watchdog_allowed_mask))
|
|
|
|
watchdog_enable(cpu);
|
2018-06-07 08:52:03 +00:00
|
|
|
return 0;
|
2017-09-12 19:37:10 +00:00
|
|
|
}
|
|
|
|
|
2018-06-07 08:52:03 +00:00
|
|
|
int lockup_detector_offline_cpu(unsigned int cpu)
|
2017-09-12 19:37:10 +00:00
|
|
|
{
|
2019-03-26 21:51:02 +00:00
|
|
|
if (cpumask_test_cpu(cpu, &watchdog_allowed_mask))
|
|
|
|
watchdog_disable(cpu);
|
2018-06-07 08:52:03 +00:00
|
|
|
return 0;
|
2017-09-12 19:37:10 +00:00
|
|
|
}
|
|
|
|
|
2022-07-13 15:47:27 +00:00
|
|
|
static void __lockup_detector_reconfigure(void)
|
2017-09-12 19:37:10 +00:00
|
|
|
{
|
2017-10-03 14:37:53 +00:00
|
|
|
cpus_read_lock();
|
2023-05-19 17:18:36 +00:00
|
|
|
watchdog_hardlockup_stop();
|
2018-06-07 08:52:03 +00:00
|
|
|
|
|
|
|
softlockup_stop_all();
|
2017-09-12 19:37:10 +00:00
|
|
|
set_sample_period();
|
2017-09-12 19:37:17 +00:00
|
|
|
lockup_detector_update_enable();
|
|
|
|
if (watchdog_enabled && watchdog_thresh)
|
2018-06-07 08:52:03 +00:00
|
|
|
softlockup_start_all();
|
|
|
|
|
2023-05-19 17:18:36 +00:00
|
|
|
watchdog_hardlockup_start();
|
2017-10-03 14:37:53 +00:00
|
|
|
cpus_read_unlock();
|
|
|
|
/*
|
|
|
|
* Must be called outside the cpus locked section to prevent
|
|
|
|
* recursive locking in the perf code.
|
|
|
|
*/
|
|
|
|
__lockup_detector_cleanup();
|
2017-09-12 19:37:10 +00:00
|
|
|
}
|
|
|
|
|
2022-07-13 15:47:27 +00:00
|
|
|
void lockup_detector_reconfigure(void)
|
|
|
|
{
|
|
|
|
mutex_lock(&watchdog_mutex);
|
|
|
|
__lockup_detector_reconfigure();
|
|
|
|
mutex_unlock(&watchdog_mutex);
|
|
|
|
}
|
|
|
|
|
2017-09-12 19:37:10 +00:00
|
|
|
/*
|
2021-06-29 02:34:17 +00:00
|
|
|
* Create the watchdog infrastructure and configure the detector(s).
|
2017-09-12 19:37:10 +00:00
|
|
|
*/
|
2017-10-04 08:03:04 +00:00
|
|
|
static __init void lockup_detector_setup(void)
|
2017-09-12 19:37:10 +00:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If sysctl is off and watchdog got disabled on the command line,
|
|
|
|
* nothing to do here.
|
|
|
|
*/
|
2017-09-12 19:37:17 +00:00
|
|
|
lockup_detector_update_enable();
|
|
|
|
|
2017-09-12 19:37:10 +00:00
|
|
|
if (!IS_ENABLED(CONFIG_SYSCTL) &&
|
|
|
|
!(watchdog_enabled && watchdog_thresh))
|
|
|
|
return;
|
|
|
|
|
|
|
|
mutex_lock(&watchdog_mutex);
|
2022-07-13 15:47:27 +00:00
|
|
|
__lockup_detector_reconfigure();
|
2018-06-07 08:52:03 +00:00
|
|
|
softlockup_initialized = true;
|
2017-09-12 19:37:10 +00:00
|
|
|
mutex_unlock(&watchdog_mutex);
|
|
|
|
}
|
|
|
|
|
2017-09-12 19:37:06 +00:00
|
|
|
#else /* CONFIG_SOFTLOCKUP_DETECTOR */
|
2022-07-13 15:47:27 +00:00
|
|
|
static void __lockup_detector_reconfigure(void)
|
2017-09-12 19:37:16 +00:00
|
|
|
{
|
2017-10-03 14:37:53 +00:00
|
|
|
cpus_read_lock();
|
2023-05-19 17:18:36 +00:00
|
|
|
watchdog_hardlockup_stop();
|
2017-09-12 19:37:17 +00:00
|
|
|
lockup_detector_update_enable();
|
2023-05-19 17:18:36 +00:00
|
|
|
watchdog_hardlockup_start();
|
2017-10-03 14:37:53 +00:00
|
|
|
cpus_read_unlock();
|
2017-09-12 19:37:16 +00:00
|
|
|
}
|
2022-07-13 15:47:27 +00:00
|
|
|
void lockup_detector_reconfigure(void)
|
|
|
|
{
|
|
|
|
__lockup_detector_reconfigure();
|
|
|
|
}
|
2017-10-04 08:03:04 +00:00
|
|
|
static inline void lockup_detector_setup(void)
|
2017-10-03 14:39:02 +00:00
|
|
|
{
|
2022-07-13 15:47:27 +00:00
|
|
|
__lockup_detector_reconfigure();
|
2017-10-03 14:39:02 +00:00
|
|
|
}
|
2017-09-12 19:37:06 +00:00
|
|
|
#endif /* !CONFIG_SOFTLOCKUP_DETECTOR */
|
2017-07-12 21:35:46 +00:00
|
|
|
|
2017-09-12 19:37:04 +00:00
|
|
|
static void __lockup_detector_cleanup(void)
|
|
|
|
{
|
|
|
|
lockdep_assert_held(&watchdog_mutex);
|
|
|
|
hardlockup_detector_perf_cleanup();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* lockup_detector_cleanup - Cleanup after cpu hotplug or sysctl changes
|
|
|
|
*
|
|
|
|
* Caller must not hold the cpu hotplug rwsem.
|
|
|
|
*/
|
|
|
|
void lockup_detector_cleanup(void)
|
|
|
|
{
|
|
|
|
mutex_lock(&watchdog_mutex);
|
|
|
|
__lockup_detector_cleanup();
|
|
|
|
mutex_unlock(&watchdog_mutex);
|
|
|
|
}
|
|
|
|
|
2017-09-12 19:36:57 +00:00
|
|
|
/**
|
|
|
|
* lockup_detector_soft_poweroff - Interface to stop lockup detector(s)
|
|
|
|
*
|
|
|
|
* Special interface for parisc. It prevents lockup detector warnings from
|
|
|
|
* the default pm_poweroff() function which busy loops forever.
|
|
|
|
*/
|
|
|
|
void lockup_detector_soft_poweroff(void)
|
|
|
|
{
|
|
|
|
watchdog_enabled = 0;
|
|
|
|
}
|
|
|
|
|
2015-11-06 02:44:30 +00:00
|
|
|
#ifdef CONFIG_SYSCTL
|
|
|
|
|
2021-06-29 02:34:17 +00:00
|
|
|
/* Propagate any changes to the watchdog infrastructure */
|
2017-09-12 19:37:11 +00:00
|
|
|
static void proc_watchdog_update(void)
|
2015-04-14 22:43:58 +00:00
|
|
|
{
|
2017-09-12 19:37:12 +00:00
|
|
|
/* Remove impossible cpus to keep sysctl output clean. */
|
|
|
|
cpumask_and(&watchdog_cpumask, &watchdog_cpumask, cpu_possible_mask);
|
2022-07-13 15:47:27 +00:00
|
|
|
__lockup_detector_reconfigure();
|
2015-04-14 22:43:58 +00:00
|
|
|
}
|
|
|
|
|
2015-04-14 22:44:05 +00:00
|
|
|
/*
|
|
|
|
* common function for watchdog, nmi_watchdog and soft_watchdog parameter
|
|
|
|
*
|
2023-05-19 17:18:36 +00:00
|
|
|
* caller | table->data points to | 'which'
|
|
|
|
* -------------------|----------------------------------|-------------------------------
|
|
|
|
* proc_watchdog | watchdog_user_enabled | WATCHDOG_HARDLOCKUP_ENABLED |
|
|
|
|
* | | WATCHDOG_SOFTOCKUP_ENABLED
|
|
|
|
* -------------------|----------------------------------|-------------------------------
|
|
|
|
* proc_nmi_watchdog | watchdog_hardlockup_user_enabled | WATCHDOG_HARDLOCKUP_ENABLED
|
|
|
|
* -------------------|----------------------------------|-------------------------------
|
|
|
|
* proc_soft_watchdog | watchdog_softlockup_user_enabled | WATCHDOG_SOFTOCKUP_ENABLED
|
2015-04-14 22:44:05 +00:00
|
|
|
*/
|
|
|
|
static int proc_watchdog_common(int which, struct ctl_table *table, int write,
|
2020-04-24 06:43:38 +00:00
|
|
|
void *buffer, size_t *lenp, loff_t *ppos)
|
2015-04-14 22:44:05 +00:00
|
|
|
{
|
2017-09-12 19:37:17 +00:00
|
|
|
int err, old, *param = table->data;
|
2015-04-14 22:44:05 +00:00
|
|
|
|
2017-09-12 19:37:01 +00:00
|
|
|
mutex_lock(&watchdog_mutex);
|
2015-04-14 22:44:05 +00:00
|
|
|
|
|
|
|
if (!write) {
|
2017-09-12 19:37:17 +00:00
|
|
|
/*
|
|
|
|
* On read synchronize the userspace interface. This is a
|
|
|
|
* racy snapshot.
|
|
|
|
*/
|
|
|
|
*param = (watchdog_enabled & which) != 0;
|
2015-04-14 22:44:05 +00:00
|
|
|
err = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
|
|
|
|
} else {
|
2017-09-12 19:37:17 +00:00
|
|
|
old = READ_ONCE(*param);
|
2015-04-14 22:44:05 +00:00
|
|
|
err = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
|
2017-09-12 19:37:17 +00:00
|
|
|
if (!err && old != READ_ONCE(*param))
|
2017-09-12 19:37:11 +00:00
|
|
|
proc_watchdog_update();
|
2015-04-14 22:44:05 +00:00
|
|
|
}
|
2017-09-12 19:37:01 +00:00
|
|
|
mutex_unlock(&watchdog_mutex);
|
2015-04-14 22:44:05 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2015-04-14 22:44:08 +00:00
|
|
|
/*
|
|
|
|
* /proc/sys/kernel/watchdog
|
|
|
|
*/
|
|
|
|
int proc_watchdog(struct ctl_table *table, int write,
|
2020-04-24 06:43:38 +00:00
|
|
|
void *buffer, size_t *lenp, loff_t *ppos)
|
2015-04-14 22:44:08 +00:00
|
|
|
{
|
2023-05-19 17:18:36 +00:00
|
|
|
return proc_watchdog_common(WATCHDOG_HARDLOCKUP_ENABLED |
|
|
|
|
WATCHDOG_SOFTOCKUP_ENABLED,
|
2015-04-14 22:44:08 +00:00
|
|
|
table, write, buffer, lenp, ppos);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* /proc/sys/kernel/nmi_watchdog
|
2010-05-07 21:11:44 +00:00
|
|
|
*/
|
2015-04-14 22:44:08 +00:00
|
|
|
int proc_nmi_watchdog(struct ctl_table *table, int write,
|
2020-04-24 06:43:38 +00:00
|
|
|
void *buffer, size_t *lenp, loff_t *ppos)
|
2015-04-14 22:44:08 +00:00
|
|
|
{
|
2023-05-19 17:18:36 +00:00
|
|
|
if (!watchdog_hardlockup_available && write)
|
2017-09-12 19:37:19 +00:00
|
|
|
return -ENOTSUPP;
|
2023-05-19 17:18:36 +00:00
|
|
|
return proc_watchdog_common(WATCHDOG_HARDLOCKUP_ENABLED,
|
2015-04-14 22:44:08 +00:00
|
|
|
table, write, buffer, lenp, ppos);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* /proc/sys/kernel/soft_watchdog
|
|
|
|
*/
|
|
|
|
int proc_soft_watchdog(struct ctl_table *table, int write,
|
2020-04-24 06:43:38 +00:00
|
|
|
void *buffer, size_t *lenp, loff_t *ppos)
|
2015-04-14 22:44:08 +00:00
|
|
|
{
|
2023-05-19 17:18:36 +00:00
|
|
|
return proc_watchdog_common(WATCHDOG_SOFTOCKUP_ENABLED,
|
2015-04-14 22:44:08 +00:00
|
|
|
table, write, buffer, lenp, ppos);
|
|
|
|
}
|
2010-05-07 21:11:44 +00:00
|
|
|
|
2015-04-14 22:44:08 +00:00
|
|
|
/*
|
|
|
|
* /proc/sys/kernel/watchdog_thresh
|
|
|
|
*/
|
|
|
|
int proc_watchdog_thresh(struct ctl_table *table, int write,
|
2020-04-24 06:43:38 +00:00
|
|
|
void *buffer, size_t *lenp, loff_t *ppos)
|
2010-05-07 21:11:44 +00:00
|
|
|
{
|
2017-09-12 19:37:11 +00:00
|
|
|
int err, old;
|
2010-05-07 21:11:44 +00:00
|
|
|
|
2017-09-12 19:37:01 +00:00
|
|
|
mutex_lock(&watchdog_mutex);
|
2012-07-16 10:42:38 +00:00
|
|
|
|
2017-09-12 19:37:11 +00:00
|
|
|
old = READ_ONCE(watchdog_thresh);
|
2013-06-06 13:42:53 +00:00
|
|
|
err = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
|
2015-04-14 22:44:08 +00:00
|
|
|
|
2017-09-12 19:37:11 +00:00
|
|
|
if (!err && write && old != READ_ONCE(watchdog_thresh))
|
|
|
|
proc_watchdog_update();
|
2011-05-23 05:10:21 +00:00
|
|
|
|
2017-09-12 19:37:01 +00:00
|
|
|
mutex_unlock(&watchdog_mutex);
|
2013-06-06 13:42:53 +00:00
|
|
|
return err;
|
2010-05-07 21:11:44 +00:00
|
|
|
}
|
2015-06-24 23:55:45 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The cpumask is the mask of possible cpus that the watchdog can run
|
|
|
|
* on, not the mask of cpus it is actually running on. This allows the
|
|
|
|
* user to specify a mask that will include cpus that have not yet
|
|
|
|
* been brought online, if desired.
|
|
|
|
*/
|
|
|
|
int proc_watchdog_cpumask(struct ctl_table *table, int write,
|
2020-04-24 06:43:38 +00:00
|
|
|
void *buffer, size_t *lenp, loff_t *ppos)
|
2015-06-24 23:55:45 +00:00
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2017-09-12 19:37:01 +00:00
|
|
|
mutex_lock(&watchdog_mutex);
|
2015-09-04 22:45:18 +00:00
|
|
|
|
2015-06-24 23:55:45 +00:00
|
|
|
err = proc_do_large_bitmap(table, write, buffer, lenp, ppos);
|
2017-09-12 19:37:08 +00:00
|
|
|
if (!err && write)
|
2017-09-12 19:37:12 +00:00
|
|
|
proc_watchdog_update();
|
2017-09-12 19:36:59 +00:00
|
|
|
|
2017-09-12 19:37:01 +00:00
|
|
|
mutex_unlock(&watchdog_mutex);
|
2015-06-24 23:55:45 +00:00
|
|
|
return err;
|
|
|
|
}
|
2022-01-22 06:11:05 +00:00
|
|
|
|
|
|
|
static const int sixty = 60;
|
|
|
|
|
|
|
|
static struct ctl_table watchdog_sysctls[] = {
|
|
|
|
{
|
|
|
|
.procname = "watchdog",
|
|
|
|
.data = &watchdog_user_enabled,
|
|
|
|
.maxlen = sizeof(int),
|
|
|
|
.mode = 0644,
|
|
|
|
.proc_handler = proc_watchdog,
|
|
|
|
.extra1 = SYSCTL_ZERO,
|
|
|
|
.extra2 = SYSCTL_ONE,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.procname = "watchdog_thresh",
|
|
|
|
.data = &watchdog_thresh,
|
|
|
|
.maxlen = sizeof(int),
|
|
|
|
.mode = 0644,
|
|
|
|
.proc_handler = proc_watchdog_thresh,
|
|
|
|
.extra1 = SYSCTL_ZERO,
|
|
|
|
.extra2 = (void *)&sixty,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.procname = "watchdog_cpumask",
|
|
|
|
.data = &watchdog_cpumask_bits,
|
|
|
|
.maxlen = NR_CPUS,
|
|
|
|
.mode = 0644,
|
|
|
|
.proc_handler = proc_watchdog_cpumask,
|
|
|
|
},
|
|
|
|
#ifdef CONFIG_SOFTLOCKUP_DETECTOR
|
|
|
|
{
|
|
|
|
.procname = "soft_watchdog",
|
2023-05-19 17:18:36 +00:00
|
|
|
.data = &watchdog_softlockup_user_enabled,
|
2022-01-22 06:11:05 +00:00
|
|
|
.maxlen = sizeof(int),
|
|
|
|
.mode = 0644,
|
|
|
|
.proc_handler = proc_soft_watchdog,
|
|
|
|
.extra1 = SYSCTL_ZERO,
|
|
|
|
.extra2 = SYSCTL_ONE,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.procname = "softlockup_panic",
|
|
|
|
.data = &softlockup_panic,
|
|
|
|
.maxlen = sizeof(int),
|
|
|
|
.mode = 0644,
|
|
|
|
.proc_handler = proc_dointvec_minmax,
|
|
|
|
.extra1 = SYSCTL_ZERO,
|
|
|
|
.extra2 = SYSCTL_ONE,
|
|
|
|
},
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
{
|
|
|
|
.procname = "softlockup_all_cpu_backtrace",
|
|
|
|
.data = &sysctl_softlockup_all_cpu_backtrace,
|
|
|
|
.maxlen = sizeof(int),
|
|
|
|
.mode = 0644,
|
|
|
|
.proc_handler = proc_dointvec_minmax,
|
|
|
|
.extra1 = SYSCTL_ZERO,
|
|
|
|
.extra2 = SYSCTL_ONE,
|
|
|
|
},
|
|
|
|
#endif /* CONFIG_SMP */
|
|
|
|
#endif
|
|
|
|
#ifdef CONFIG_HARDLOCKUP_DETECTOR
|
|
|
|
{
|
|
|
|
.procname = "hardlockup_panic",
|
|
|
|
.data = &hardlockup_panic,
|
|
|
|
.maxlen = sizeof(int),
|
|
|
|
.mode = 0644,
|
|
|
|
.proc_handler = proc_dointvec_minmax,
|
|
|
|
.extra1 = SYSCTL_ZERO,
|
|
|
|
.extra2 = SYSCTL_ONE,
|
|
|
|
},
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
{
|
|
|
|
.procname = "hardlockup_all_cpu_backtrace",
|
|
|
|
.data = &sysctl_hardlockup_all_cpu_backtrace,
|
|
|
|
.maxlen = sizeof(int),
|
|
|
|
.mode = 0644,
|
|
|
|
.proc_handler = proc_dointvec_minmax,
|
|
|
|
.extra1 = SYSCTL_ZERO,
|
|
|
|
.extra2 = SYSCTL_ONE,
|
|
|
|
},
|
|
|
|
#endif /* CONFIG_SMP */
|
|
|
|
#endif
|
|
|
|
{}
|
|
|
|
};
|
|
|
|
|
2023-05-27 01:41:31 +00:00
|
|
|
static struct ctl_table watchdog_hardlockup_sysctl[] = {
|
|
|
|
{
|
|
|
|
.procname = "nmi_watchdog",
|
|
|
|
.data = &watchdog_hardlockup_user_enabled,
|
|
|
|
.maxlen = sizeof(int),
|
|
|
|
.mode = 0444,
|
|
|
|
.proc_handler = proc_nmi_watchdog,
|
|
|
|
.extra1 = SYSCTL_ZERO,
|
|
|
|
.extra2 = SYSCTL_ONE,
|
|
|
|
},
|
|
|
|
{}
|
|
|
|
};
|
|
|
|
|
2022-01-22 06:11:05 +00:00
|
|
|
static void __init watchdog_sysctl_init(void)
|
|
|
|
{
|
|
|
|
register_sysctl_init("kernel", watchdog_sysctls);
|
2023-05-27 01:41:31 +00:00
|
|
|
|
|
|
|
if (watchdog_hardlockup_available)
|
|
|
|
watchdog_hardlockup_sysctl[0].mode = 0644;
|
|
|
|
register_sysctl_init("kernel", watchdog_hardlockup_sysctl);
|
2022-01-22 06:11:05 +00:00
|
|
|
}
|
2023-05-27 01:41:31 +00:00
|
|
|
|
2022-01-22 06:11:05 +00:00
|
|
|
#else
|
|
|
|
#define watchdog_sysctl_init() do { } while (0)
|
2010-05-07 21:11:44 +00:00
|
|
|
#endif /* CONFIG_SYSCTL */
|
|
|
|
|
2023-05-19 17:18:40 +00:00
|
|
|
static void __init lockup_detector_delay_init(struct work_struct *work);
|
|
|
|
static bool allow_lockup_detector_init_retry __initdata;
|
|
|
|
|
|
|
|
static struct work_struct detector_work __initdata =
|
|
|
|
__WORK_INITIALIZER(detector_work, lockup_detector_delay_init);
|
|
|
|
|
|
|
|
static void __init lockup_detector_delay_init(struct work_struct *work)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = watchdog_hardlockup_probe();
|
|
|
|
if (ret) {
|
|
|
|
pr_info("Delayed init of the lockup detector failed: %d\n", ret);
|
|
|
|
pr_info("Hard watchdog permanently disabled\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
allow_lockup_detector_init_retry = false;
|
|
|
|
|
|
|
|
watchdog_hardlockup_available = true;
|
|
|
|
lockup_detector_setup();
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* lockup_detector_retry_init - retry init lockup detector if possible.
|
|
|
|
*
|
|
|
|
* Retry hardlockup detector init. It is useful when it requires some
|
|
|
|
* functionality that has to be initialized later on a particular
|
|
|
|
* platform.
|
|
|
|
*/
|
|
|
|
void __init lockup_detector_retry_init(void)
|
|
|
|
{
|
|
|
|
/* Must be called before late init calls */
|
|
|
|
if (!allow_lockup_detector_init_retry)
|
|
|
|
return;
|
|
|
|
|
|
|
|
schedule_work(&detector_work);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ensure that optional delayed hardlockup init is proceed before
|
|
|
|
* the init code and memory is freed.
|
|
|
|
*/
|
|
|
|
static int __init lockup_detector_check(void)
|
|
|
|
{
|
|
|
|
/* Prevent any later retry. */
|
|
|
|
allow_lockup_detector_init_retry = false;
|
|
|
|
|
|
|
|
/* Make sure no work is pending. */
|
|
|
|
flush_work(&detector_work);
|
|
|
|
|
2023-05-27 01:41:31 +00:00
|
|
|
watchdog_sysctl_init();
|
|
|
|
|
2023-05-19 17:18:40 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
}
|
|
|
|
late_initcall_sync(lockup_detector_check);
|
|
|
|
|
2010-11-25 17:38:29 +00:00
|
|
|
void __init lockup_detector_init(void)
|
2010-05-07 21:11:44 +00:00
|
|
|
{
|
2017-10-27 02:42:29 +00:00
|
|
|
if (tick_nohz_full_enabled())
|
2015-09-04 22:45:09 +00:00
|
|
|
pr_info("Disabling watchdog on nohz_full cores by default\n");
|
2017-10-27 02:42:29 +00:00
|
|
|
|
2017-10-27 02:42:35 +00:00
|
|
|
cpumask_copy(&watchdog_cpumask,
|
2022-02-07 15:59:06 +00:00
|
|
|
housekeeping_cpumask(HK_TYPE_TIMER));
|
2015-06-24 23:55:45 +00:00
|
|
|
|
2023-05-19 17:18:36 +00:00
|
|
|
if (!watchdog_hardlockup_probe())
|
|
|
|
watchdog_hardlockup_available = true;
|
2023-05-19 17:18:40 +00:00
|
|
|
else
|
|
|
|
allow_lockup_detector_init_retry = true;
|
|
|
|
|
2017-10-04 08:03:04 +00:00
|
|
|
lockup_detector_setup();
|
2010-05-07 21:11:44 +00:00
|
|
|
}
|