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 07:07:57 -07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2010-05-07 14:11:44 -07:00
|
|
|
/*
|
|
|
|
* Detect hard and soft lockups on a system
|
|
|
|
*
|
|
|
|
* started by Don Zickus, Copyright (C) 2010 Red Hat, Inc.
|
|
|
|
*
|
2012-02-09 15:42:22 -07: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 14:11:44 -07:00
|
|
|
* to those contributors as well.
|
|
|
|
*/
|
|
|
|
|
2017-07-14 14:49:46 -07:00
|
|
|
#define pr_fmt(fmt) "watchdog: " fmt
|
2012-03-23 15:01:55 -07:00
|
|
|
|
2010-05-07 14:11:44 -07:00
|
|
|
#include <linux/cpu.h>
|
|
|
|
#include <linux/init.h>
|
watchdog/softlockup: Report the most frequent interrupts
When the watchdog determines that the current soft lockup is due to an
interrupt storm based on CPU utilization, reporting the most frequent
interrupts could be good enough for further troubleshooting.
Below is an example of interrupt storm. The call tree does not provide
useful information, but analyzing which interrupt caused the soft lockup by
comparing the counts of interrupts during the lockup period allows to
identify the culprit.
[ 638.870231] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [swapper/9:0]
[ 638.870825] CPU#9 Utilization every 4s during lockup:
[ 638.871194] #1: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.871652] #2: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872107] #3: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872563] #4: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873018] #5: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873494] CPU#9 Detect HardIRQ Time exceeds 50%. Most frequent HardIRQs:
[ 638.873994] #1: 330945 irq#7
[ 638.874236] #2: 31 irq#82
[ 638.874493] #3: 10 irq#10
[ 638.874744] #4: 2 irq#89
[ 638.874992] #5: 1 irq#102
...
[ 638.875313] Call trace:
[ 638.875315] __do_softirq+0xa8/0x364
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20240411074134.30922-6-yaoma@linux.alibaba.com
2024-04-11 00:41:34 -07:00
|
|
|
#include <linux/irq.h>
|
|
|
|
#include <linux/irqdesc.h>
|
watchdog/softlockup: Low-overhead detection of interrupt storm
The following softlockup is caused by interrupt storm, but it cannot be
identified from the call tree. Because the call tree is just a snapshot
and doesn't fully capture the behavior of the CPU during the soft lockup.
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
...
Call trace:
__do_softirq+0xa0/0x37c
__irq_exit_rcu+0x108/0x140
irq_exit+0x14/0x20
__handle_domain_irq+0x84/0xe0
gic_handle_irq+0x80/0x108
el0_irq_naked+0x50/0x58
Therefore, it is necessary to report CPU utilization during the
softlockup_threshold period (report once every sample_period, for a total
of 5 reportings), like this:
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
CPU#28 Utilization every 4s during lockup:
#1: 0% system, 0% softirq, 100% hardirq, 0% idle
#2: 0% system, 0% softirq, 100% hardirq, 0% idle
#3: 0% system, 0% softirq, 100% hardirq, 0% idle
#4: 0% system, 0% softirq, 100% hardirq, 0% idle
#5: 0% system, 0% softirq, 100% hardirq, 0% idle
...
This is helpful in determining whether an interrupt storm has occurred or
in identifying the cause of the softlockup. The criteria for determination
are as follows:
a. If the hardirq utilization is high, then interrupt storm should be
considered and the root cause cannot be determined from the call tree.
b. If the softirq utilization is high, then the call might not necessarily
point at the root cause.
c. If the system utilization is high, then analyzing the root
cause from the call tree is possible in most cases.
The mechanism requires a considerable amount of global storage space
when configured for the maximum number of CPUs. Therefore, adding a
SOFTLOCKUP_DETECTOR_INTR_STORM Kconfig knob that defaults to "yes"
if the max number of CPUs is <= 128.
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240411074134.30922-5-yaoma@linux.alibaba.com
2024-04-11 00:41:33 -07:00
|
|
|
#include <linux/kernel_stat.h>
|
watchdog/softlockup: Report the most frequent interrupts
When the watchdog determines that the current soft lockup is due to an
interrupt storm based on CPU utilization, reporting the most frequent
interrupts could be good enough for further troubleshooting.
Below is an example of interrupt storm. The call tree does not provide
useful information, but analyzing which interrupt caused the soft lockup by
comparing the counts of interrupts during the lockup period allows to
identify the culprit.
[ 638.870231] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [swapper/9:0]
[ 638.870825] CPU#9 Utilization every 4s during lockup:
[ 638.871194] #1: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.871652] #2: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872107] #3: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872563] #4: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873018] #5: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873494] CPU#9 Detect HardIRQ Time exceeds 50%. Most frequent HardIRQs:
[ 638.873994] #1: 330945 irq#7
[ 638.874236] #2: 31 irq#82
[ 638.874493] #3: 10 irq#10
[ 638.874744] #4: 2 irq#89
[ 638.874992] #5: 1 irq#102
...
[ 638.875313] Call trace:
[ 638.875315] __do_softirq+0xa8/0x364
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20240411074134.30922-6-yaoma@linux.alibaba.com
2024-04-11 00:41:34 -07:00
|
|
|
#include <linux/kvm_para.h>
|
watchdog/softlockup: Low-overhead detection of interrupt storm
The following softlockup is caused by interrupt storm, but it cannot be
identified from the call tree. Because the call tree is just a snapshot
and doesn't fully capture the behavior of the CPU during the soft lockup.
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
...
Call trace:
__do_softirq+0xa0/0x37c
__irq_exit_rcu+0x108/0x140
irq_exit+0x14/0x20
__handle_domain_irq+0x84/0xe0
gic_handle_irq+0x80/0x108
el0_irq_naked+0x50/0x58
Therefore, it is necessary to report CPU utilization during the
softlockup_threshold period (report once every sample_period, for a total
of 5 reportings), like this:
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
CPU#28 Utilization every 4s during lockup:
#1: 0% system, 0% softirq, 100% hardirq, 0% idle
#2: 0% system, 0% softirq, 100% hardirq, 0% idle
#3: 0% system, 0% softirq, 100% hardirq, 0% idle
#4: 0% system, 0% softirq, 100% hardirq, 0% idle
#5: 0% system, 0% softirq, 100% hardirq, 0% idle
...
This is helpful in determining whether an interrupt storm has occurred or
in identifying the cause of the softlockup. The criteria for determination
are as follows:
a. If the hardirq utilization is high, then interrupt storm should be
considered and the root cause cannot be determined from the call tree.
b. If the softirq utilization is high, then the call might not necessarily
point at the root cause.
c. If the system utilization is high, then analyzing the root
cause from the call tree is possible in most cases.
The mechanism requires a considerable amount of global storage space
when configured for the maximum number of CPUs. Therefore, adding a
SOFTLOCKUP_DETECTOR_INTR_STORM Kconfig knob that defaults to "yes"
if the max number of CPUs is <= 128.
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240411074134.30922-5-yaoma@linux.alibaba.com
2024-04-11 00:41:33 -07:00
|
|
|
#include <linux/math64.h>
|
watchdog/softlockup: Report the most frequent interrupts
When the watchdog determines that the current soft lockup is due to an
interrupt storm based on CPU utilization, reporting the most frequent
interrupts could be good enough for further troubleshooting.
Below is an example of interrupt storm. The call tree does not provide
useful information, but analyzing which interrupt caused the soft lockup by
comparing the counts of interrupts during the lockup period allows to
identify the culprit.
[ 638.870231] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [swapper/9:0]
[ 638.870825] CPU#9 Utilization every 4s during lockup:
[ 638.871194] #1: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.871652] #2: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872107] #3: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872563] #4: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873018] #5: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873494] CPU#9 Detect HardIRQ Time exceeds 50%. Most frequent HardIRQs:
[ 638.873994] #1: 330945 irq#7
[ 638.874236] #2: 31 irq#82
[ 638.874493] #3: 10 irq#10
[ 638.874744] #4: 2 irq#89
[ 638.874992] #5: 1 irq#102
...
[ 638.875313] Call trace:
[ 638.875315] __do_softirq+0xa8/0x364
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20240411074134.30922-6-yaoma@linux.alibaba.com
2024-04-11 00:41:34 -07:00
|
|
|
#include <linux/mm.h>
|
2010-05-07 14:11:44 -07:00
|
|
|
#include <linux/module.h>
|
watchdog/softlockup: Report the most frequent interrupts
When the watchdog determines that the current soft lockup is due to an
interrupt storm based on CPU utilization, reporting the most frequent
interrupts could be good enough for further troubleshooting.
Below is an example of interrupt storm. The call tree does not provide
useful information, but analyzing which interrupt caused the soft lockup by
comparing the counts of interrupts during the lockup period allows to
identify the culprit.
[ 638.870231] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [swapper/9:0]
[ 638.870825] CPU#9 Utilization every 4s during lockup:
[ 638.871194] #1: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.871652] #2: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872107] #3: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872563] #4: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873018] #5: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873494] CPU#9 Detect HardIRQ Time exceeds 50%. Most frequent HardIRQs:
[ 638.873994] #1: 330945 irq#7
[ 638.874236] #2: 31 irq#82
[ 638.874493] #3: 10 irq#10
[ 638.874744] #4: 2 irq#89
[ 638.874992] #5: 1 irq#102
...
[ 638.875313] Call trace:
[ 638.875315] __do_softirq+0xa8/0x364
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20240411074134.30922-6-yaoma@linux.alibaba.com
2024-04-11 00:41:34 -07:00
|
|
|
#include <linux/nmi.h>
|
|
|
|
#include <linux/stop_machine.h>
|
2010-05-07 14:11:44 -07:00
|
|
|
#include <linux/sysctl.h>
|
2015-06-24 16:55:45 -07:00
|
|
|
#include <linux/tick.h>
|
watchdog/softlockup: Report the most frequent interrupts
When the watchdog determines that the current soft lockup is due to an
interrupt storm based on CPU utilization, reporting the most frequent
interrupts could be good enough for further troubleshooting.
Below is an example of interrupt storm. The call tree does not provide
useful information, but analyzing which interrupt caused the soft lockup by
comparing the counts of interrupts during the lockup period allows to
identify the culprit.
[ 638.870231] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [swapper/9:0]
[ 638.870825] CPU#9 Utilization every 4s during lockup:
[ 638.871194] #1: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.871652] #2: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872107] #3: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872563] #4: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873018] #5: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873494] CPU#9 Detect HardIRQ Time exceeds 50%. Most frequent HardIRQs:
[ 638.873994] #1: 330945 irq#7
[ 638.874236] #2: 31 irq#82
[ 638.874493] #3: 10 irq#10
[ 638.874744] #4: 2 irq#89
[ 638.874992] #5: 1 irq#102
...
[ 638.875313] Call trace:
[ 638.875315] __do_softirq+0xa8/0x364
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20240411074134.30922-6-yaoma@linux.alibaba.com
2024-04-11 00:41:34 -07:00
|
|
|
|
2017-02-01 08:36:40 -07:00
|
|
|
#include <linux/sched/clock.h>
|
2017-02-08 10:51:35 -07:00
|
|
|
#include <linux/sched/debug.h>
|
2017-10-26 19:42:28 -07:00
|
|
|
#include <linux/sched/isolation.h>
|
2010-05-07 14:11:44 -07:00
|
|
|
|
|
|
|
#include <asm/irq_regs.h>
|
|
|
|
|
2017-09-12 12:37:01 -07:00
|
|
|
static DEFINE_MUTEX(watchdog_mutex);
|
2015-05-18 02:31:50 -07:00
|
|
|
|
2023-06-16 08:06:17 -07:00
|
|
|
#if defined(CONFIG_HARDLOCKUP_DETECTOR) || defined(CONFIG_HARDLOCKUP_DETECTOR_SPARC64)
|
2023-05-19 10:18:36 -07:00
|
|
|
# define WATCHDOG_HARDLOCKUP_DEFAULT 1
|
2015-04-14 15:43:55 -07:00
|
|
|
#else
|
2023-05-19 10:18:36 -07:00
|
|
|
# define WATCHDOG_HARDLOCKUP_DEFAULT 0
|
2015-04-14 15:43:55 -07:00
|
|
|
#endif
|
2017-07-12 14:35:46 -07:00
|
|
|
|
watchdog/softlockup: Low-overhead detection of interrupt storm
The following softlockup is caused by interrupt storm, but it cannot be
identified from the call tree. Because the call tree is just a snapshot
and doesn't fully capture the behavior of the CPU during the soft lockup.
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
...
Call trace:
__do_softirq+0xa0/0x37c
__irq_exit_rcu+0x108/0x140
irq_exit+0x14/0x20
__handle_domain_irq+0x84/0xe0
gic_handle_irq+0x80/0x108
el0_irq_naked+0x50/0x58
Therefore, it is necessary to report CPU utilization during the
softlockup_threshold period (report once every sample_period, for a total
of 5 reportings), like this:
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
CPU#28 Utilization every 4s during lockup:
#1: 0% system, 0% softirq, 100% hardirq, 0% idle
#2: 0% system, 0% softirq, 100% hardirq, 0% idle
#3: 0% system, 0% softirq, 100% hardirq, 0% idle
#4: 0% system, 0% softirq, 100% hardirq, 0% idle
#5: 0% system, 0% softirq, 100% hardirq, 0% idle
...
This is helpful in determining whether an interrupt storm has occurred or
in identifying the cause of the softlockup. The criteria for determination
are as follows:
a. If the hardirq utilization is high, then interrupt storm should be
considered and the root cause cannot be determined from the call tree.
b. If the softirq utilization is high, then the call might not necessarily
point at the root cause.
c. If the system utilization is high, then analyzing the root
cause from the call tree is possible in most cases.
The mechanism requires a considerable amount of global storage space
when configured for the maximum number of CPUs. Therefore, adding a
SOFTLOCKUP_DETECTOR_INTR_STORM Kconfig knob that defaults to "yes"
if the max number of CPUs is <= 128.
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240411074134.30922-5-yaoma@linux.alibaba.com
2024-04-11 00:41:33 -07:00
|
|
|
#define NUM_SAMPLE_PERIODS 5
|
|
|
|
|
2017-09-12 12:37:17 -07:00
|
|
|
unsigned long __read_mostly watchdog_enabled;
|
|
|
|
int __read_mostly watchdog_user_enabled = 1;
|
2023-05-19 10:18:36 -07:00
|
|
|
static int __read_mostly watchdog_hardlockup_user_enabled = WATCHDOG_HARDLOCKUP_DEFAULT;
|
|
|
|
static int __read_mostly watchdog_softlockup_user_enabled = 1;
|
2017-09-12 12:37:15 -07:00
|
|
|
int __read_mostly watchdog_thresh = 10;
|
2023-05-19 10:18:36 -07:00
|
|
|
static int __read_mostly watchdog_hardlockup_available;
|
2017-09-12 12:37:15 -07:00
|
|
|
|
|
|
|
struct cpumask watchdog_cpumask __read_mostly;
|
|
|
|
unsigned long *watchdog_cpumask_bits = cpumask_bits(&watchdog_cpumask);
|
|
|
|
|
2017-07-12 14:35:46 -07:00
|
|
|
#ifdef CONFIG_HARDLOCKUP_DETECTOR
|
2020-06-07 21:40:42 -07:00
|
|
|
|
|
|
|
# ifdef CONFIG_SMP
|
|
|
|
int __read_mostly sysctl_hardlockup_all_cpu_backtrace;
|
|
|
|
# endif /* CONFIG_SMP */
|
|
|
|
|
2017-07-12 14:35:46 -07:00
|
|
|
/*
|
|
|
|
* Should we panic when a soft-lockup or hard-lockup occurs:
|
|
|
|
*/
|
|
|
|
unsigned int __read_mostly hardlockup_panic =
|
2022-04-29 14:38:00 -07:00
|
|
|
IS_ENABLED(CONFIG_BOOTPARAM_HARDLOCKUP_PANIC);
|
2017-07-12 14:35:46 -07: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 12:37:02 -07:00
|
|
|
void __init hardlockup_detector_disable(void)
|
2017-07-12 14:35:46 -07:00
|
|
|
{
|
2023-05-19 10:18:36 -07:00
|
|
|
watchdog_hardlockup_user_enabled = 0;
|
2017-07-12 14:35:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static int __init hardlockup_panic_setup(char *str)
|
|
|
|
{
|
2024-04-29 23:02:35 -07:00
|
|
|
next:
|
2017-07-12 14:35:46 -07:00
|
|
|
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 10:18:36 -07:00
|
|
|
watchdog_hardlockup_user_enabled = 0;
|
2017-07-12 14:35:46 -07:00
|
|
|
else if (!strncmp(str, "1", 1))
|
2023-05-19 10:18:36 -07:00
|
|
|
watchdog_hardlockup_user_enabled = 1;
|
2024-04-29 23:02:36 -07:00
|
|
|
else if (!strncmp(str, "r", 1))
|
|
|
|
hardlockup_config_perf_event(str + 1);
|
2024-04-29 23:02:35 -07:00
|
|
|
while (*(str++)) {
|
|
|
|
if (*str == ',') {
|
|
|
|
str++;
|
|
|
|
goto next;
|
|
|
|
}
|
|
|
|
}
|
2017-07-12 14:35:46 -07:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
__setup("nmi_watchdog=", hardlockup_panic_setup);
|
|
|
|
|
2017-09-12 12:37:07 -07:00
|
|
|
#endif /* CONFIG_HARDLOCKUP_DETECTOR */
|
2017-07-12 14:35:46 -07: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 10:18:38 -07:00
|
|
|
#if defined(CONFIG_HARDLOCKUP_DETECTOR_COUNTS_HRTIMER)
|
2023-05-19 10:18:32 -07:00
|
|
|
|
2023-05-19 10:18:34 -07:00
|
|
|
static DEFINE_PER_CPU(atomic_t, hrtimer_interrupts);
|
|
|
|
static DEFINE_PER_CPU(int, hrtimer_interrupts_saved);
|
2023-05-19 10:18:33 -07:00
|
|
|
static DEFINE_PER_CPU(bool, watchdog_hardlockup_warned);
|
2023-05-19 10:18:35 -07:00
|
|
|
static DEFINE_PER_CPU(bool, watchdog_hardlockup_touched);
|
2023-12-20 14:15:34 -07:00
|
|
|
static unsigned long hard_lockup_nmi_warn;
|
2023-05-19 10:18:32 -07:00
|
|
|
|
2023-05-19 10:18:35 -07: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 10:18:38 -07:00
|
|
|
void watchdog_hardlockup_touch_cpu(unsigned int cpu)
|
|
|
|
{
|
|
|
|
per_cpu(watchdog_hardlockup_touched, cpu) = true;
|
|
|
|
}
|
|
|
|
|
2023-05-19 10:18:34 -07:00
|
|
|
static bool is_hardlockup(unsigned int cpu)
|
2023-05-19 10:18:32 -07:00
|
|
|
{
|
2023-05-19 10:18:34 -07:00
|
|
|
int hrint = atomic_read(&per_cpu(hrtimer_interrupts, cpu));
|
2023-05-19 10:18:32 -07:00
|
|
|
|
2023-05-19 10:18:34 -07:00
|
|
|
if (per_cpu(hrtimer_interrupts_saved, cpu) == hrint)
|
2023-05-19 10:18:32 -07:00
|
|
|
return true;
|
|
|
|
|
2023-05-19 10:18:34 -07: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 10:18:33 -07:00
|
|
|
|
2023-05-19 10:18:32 -07:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2023-05-26 18:41:36 -07:00
|
|
|
static void watchdog_hardlockup_kick(void)
|
2023-05-19 10:18:32 -07:00
|
|
|
{
|
2023-05-26 18:41:36 -07:00
|
|
|
int new_interrupts;
|
|
|
|
|
|
|
|
new_interrupts = atomic_inc_return(this_cpu_ptr(&hrtimer_interrupts));
|
|
|
|
watchdog_buddy_check_hardlockup(new_interrupts);
|
2023-05-19 10:18:32 -07:00
|
|
|
}
|
|
|
|
|
2023-05-19 10:18:34 -07:00
|
|
|
void watchdog_hardlockup_check(unsigned int cpu, struct pt_regs *regs)
|
2023-05-19 10:18:32 -07:00
|
|
|
{
|
2023-05-19 10:18:35 -07:00
|
|
|
if (per_cpu(watchdog_hardlockup_touched, cpu)) {
|
|
|
|
per_cpu(watchdog_hardlockup_touched, cpu) = false;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2023-05-19 10:18:33 -07: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 10:18:32 -07:00
|
|
|
* then this is a good indication the cpu is stuck
|
|
|
|
*/
|
2023-05-19 10:18:34 -07:00
|
|
|
if (is_hardlockup(cpu)) {
|
2023-05-19 10:18:33 -07:00
|
|
|
unsigned int this_cpu = smp_processor_id();
|
2023-12-20 14:15:36 -07:00
|
|
|
unsigned long flags;
|
2023-05-19 10:18:32 -07:00
|
|
|
|
2023-05-19 10:18:33 -07:00
|
|
|
/* Only print hardlockups once. */
|
2023-05-19 10:18:34 -07:00
|
|
|
if (per_cpu(watchdog_hardlockup_warned, cpu))
|
2023-05-19 10:18:32 -07:00
|
|
|
return;
|
|
|
|
|
2023-12-20 14:15:34 -07:00
|
|
|
/*
|
|
|
|
* Prevent multiple hard-lockup reports if one cpu is already
|
|
|
|
* engaged in dumping all cpu back traces.
|
|
|
|
*/
|
|
|
|
if (sysctl_hardlockup_all_cpu_backtrace) {
|
|
|
|
if (test_and_set_bit_lock(0, &hard_lockup_nmi_warn))
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2023-12-20 14:15:36 -07:00
|
|
|
/*
|
|
|
|
* NOTE: we call printk_cpu_sync_get_irqsave() after printing
|
|
|
|
* the lockup message. While it would be nice to serialize
|
|
|
|
* that printout, we really want to make sure that if some
|
|
|
|
* other CPU somehow locked up while holding the lock associated
|
|
|
|
* with printk_cpu_sync_get_irqsave() that we can still at least
|
|
|
|
* get the message about the lockup out.
|
|
|
|
*/
|
2023-05-19 10:18:34 -07:00
|
|
|
pr_emerg("Watchdog detected hard LOCKUP on cpu %d\n", cpu);
|
2023-12-20 14:15:36 -07:00
|
|
|
printk_cpu_sync_get_irqsave(flags);
|
|
|
|
|
2023-05-19 10:18:32 -07:00
|
|
|
print_modules();
|
|
|
|
print_irqtrace_events(current);
|
2023-05-19 10:18:34 -07:00
|
|
|
if (cpu == this_cpu) {
|
|
|
|
if (regs)
|
|
|
|
show_regs(regs);
|
|
|
|
else
|
|
|
|
dump_stack();
|
2023-12-20 14:15:36 -07:00
|
|
|
printk_cpu_sync_put_irqrestore(flags);
|
2023-05-19 10:18:34 -07:00
|
|
|
} else {
|
2023-12-20 14:15:36 -07:00
|
|
|
printk_cpu_sync_put_irqrestore(flags);
|
2023-08-04 07:00:43 -07:00
|
|
|
trigger_single_cpu_backtrace(cpu);
|
2023-05-19 10:18:34 -07:00
|
|
|
}
|
2023-05-19 10:18:32 -07:00
|
|
|
|
2023-12-20 14:15:34 -07:00
|
|
|
if (sysctl_hardlockup_all_cpu_backtrace) {
|
2023-08-04 07:00:43 -07:00
|
|
|
trigger_allbutcpu_cpu_backtrace(cpu);
|
2023-12-20 14:15:37 -07:00
|
|
|
if (!hardlockup_panic)
|
|
|
|
clear_bit_unlock(0, &hard_lockup_nmi_warn);
|
2023-12-20 14:15:34 -07:00
|
|
|
}
|
2023-05-19 10:18:32 -07:00
|
|
|
|
|
|
|
if (hardlockup_panic)
|
|
|
|
nmi_panic(regs, "Hard LOCKUP");
|
|
|
|
|
2023-05-19 10:18:34 -07:00
|
|
|
per_cpu(watchdog_hardlockup_warned, cpu) = true;
|
2023-05-19 10:18:33 -07:00
|
|
|
} else {
|
2023-05-19 10:18:34 -07:00
|
|
|
per_cpu(watchdog_hardlockup_warned, cpu) = false;
|
2023-05-19 10:18:32 -07: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 10:18:38 -07:00
|
|
|
#else /* CONFIG_HARDLOCKUP_DETECTOR_COUNTS_HRTIMER */
|
2023-05-19 10:18:32 -07:00
|
|
|
|
2023-05-26 18:41:36 -07:00
|
|
|
static inline void watchdog_hardlockup_kick(void) { }
|
2023-05-19 10:18:32 -07: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 10:18:38 -07:00
|
|
|
#endif /* !CONFIG_HARDLOCKUP_DETECTOR_COUNTS_HRTIMER */
|
2023-05-19 10:18:32 -07:00
|
|
|
|
2017-07-12 14:35:46 -07:00
|
|
|
/*
|
2023-05-19 10:18:37 -07:00
|
|
|
* These functions can be overridden based on the configured hardlockdup detector.
|
2017-07-12 14:35:49 -07:00
|
|
|
*
|
2023-05-19 10:18:36 -07:00
|
|
|
* watchdog_hardlockup_enable/disable can be implemented to start and stop when
|
2023-05-19 10:18:37 -07:00
|
|
|
* softlockup watchdog start and stop. The detector must select the
|
2017-07-12 14:35:49 -07:00
|
|
|
* SOFTLOCKUP_DETECTOR Kconfig.
|
2017-07-12 14:35:46 -07:00
|
|
|
*/
|
2023-05-19 10:18:37 -07:00
|
|
|
void __weak watchdog_hardlockup_enable(unsigned int cpu) { }
|
2017-09-12 12:37:04 -07:00
|
|
|
|
2023-05-19 10:18:37 -07:00
|
|
|
void __weak watchdog_hardlockup_disable(unsigned int cpu) { }
|
2017-07-12 14:35:46 -07:00
|
|
|
|
2023-05-19 10:18:40 -07: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 10:18:36 -07:00
|
|
|
int __weak __init watchdog_hardlockup_probe(void)
|
2017-09-12 12:37:19 -07:00
|
|
|
{
|
2023-05-19 10:18:37 -07:00
|
|
|
return -ENODEV;
|
2017-09-12 12:37:19 -07:00
|
|
|
}
|
|
|
|
|
2017-09-12 12:37:16 -07:00
|
|
|
/**
|
2023-05-19 10:18:36 -07:00
|
|
|
* watchdog_hardlockup_stop - Stop the watchdog for reconfiguration
|
2017-09-12 12:37:16 -07:00
|
|
|
*
|
2017-10-02 03:34:50 -07:00
|
|
|
* The reconfiguration steps are:
|
2023-05-19 10:18:36 -07:00
|
|
|
* watchdog_hardlockup_stop();
|
2017-09-12 12:37:16 -07:00
|
|
|
* update_variables();
|
2023-05-19 10:18:36 -07:00
|
|
|
* watchdog_hardlockup_start();
|
2017-10-02 03:34:50 -07:00
|
|
|
*/
|
2023-05-19 10:18:36 -07:00
|
|
|
void __weak watchdog_hardlockup_stop(void) { }
|
2017-10-02 03:34:50 -07:00
|
|
|
|
|
|
|
/**
|
2023-05-19 10:18:36 -07:00
|
|
|
* watchdog_hardlockup_start - Start the watchdog after reconfiguration
|
2017-09-12 12:37:16 -07:00
|
|
|
*
|
2023-05-19 10:18:36 -07:00
|
|
|
* Counterpart to watchdog_hardlockup_stop().
|
2017-10-02 03:34:50 -07:00
|
|
|
*
|
|
|
|
* The following variables have been updated in update_variables() and
|
|
|
|
* contain the currently valid configuration:
|
2017-09-12 12:37:15 -07:00
|
|
|
* - watchdog_enabled
|
2017-07-12 14:35:49 -07:00
|
|
|
* - watchdog_thresh
|
|
|
|
* - watchdog_cpumask
|
|
|
|
*/
|
2023-05-19 10:18:36 -07:00
|
|
|
void __weak watchdog_hardlockup_start(void) { }
|
2017-07-12 14:35:49 -07:00
|
|
|
|
2017-09-12 12:37:17 -07:00
|
|
|
/**
|
|
|
|
* lockup_detector_update_enable - Update the sysctl enable bit
|
|
|
|
*
|
2023-05-19 10:18:36 -07:00
|
|
|
* Caller needs to make sure that the hard watchdogs are off, so this
|
|
|
|
* can't race with watchdog_hardlockup_disable().
|
2017-09-12 12:37:17 -07:00
|
|
|
*/
|
|
|
|
static void lockup_detector_update_enable(void)
|
|
|
|
{
|
|
|
|
watchdog_enabled = 0;
|
|
|
|
if (!watchdog_user_enabled)
|
|
|
|
return;
|
2023-05-19 10:18:36 -07: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 12:37:17 -07:00
|
|
|
}
|
|
|
|
|
2017-07-12 14:35:46 -07:00
|
|
|
#ifdef CONFIG_SOFTLOCKUP_DETECTOR
|
|
|
|
|
2021-04-29 22:54:26 -07: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 11:17:02 -07:00
|
|
|
|
2020-06-07 21:40:42 -07:00
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
int __read_mostly sysctl_softlockup_all_cpu_backtrace;
|
|
|
|
#endif
|
|
|
|
|
2020-11-13 23:52:10 -07:00
|
|
|
static struct cpumask watchdog_allowed_mask __read_mostly;
|
|
|
|
|
2017-09-12 12:37:06 -07:00
|
|
|
/* Global variables, exported for sysctl */
|
|
|
|
unsigned int __read_mostly softlockup_panic =
|
2022-04-29 14:38:00 -07:00
|
|
|
IS_ENABLED(CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC);
|
2017-09-12 12:37:10 -07:00
|
|
|
|
2018-06-07 01:52:03 -07:00
|
|
|
static bool softlockup_initialized __read_mostly;
|
2012-12-17 16:59:50 -07:00
|
|
|
static u64 __read_mostly sample_period;
|
2010-05-07 14:11:44 -07:00
|
|
|
|
2021-04-29 22:54:26 -07:00
|
|
|
/* Timestamp taken after the last successful reschedule. */
|
2010-05-07 14:11:44 -07:00
|
|
|
static DEFINE_PER_CPU(unsigned long, watchdog_touch_ts);
|
2021-04-29 22:54:26 -07:00
|
|
|
/* Timestamp of the last softlockup report. */
|
|
|
|
static DEFINE_PER_CPU(unsigned long, watchdog_report_ts);
|
2010-05-07 14:11:44 -07:00
|
|
|
static DEFINE_PER_CPU(struct hrtimer, watchdog_hrtimer);
|
|
|
|
static DEFINE_PER_CPU(bool, softlockup_touch_sync);
|
2014-06-23 13:22:05 -07:00
|
|
|
static unsigned long soft_lockup_nmi_warn;
|
2010-05-07 14:11:44 -07:00
|
|
|
|
2023-10-27 14:46:53 -07:00
|
|
|
static int __init softlockup_panic_setup(char *str)
|
|
|
|
{
|
|
|
|
softlockup_panic = simple_strtoul(str, NULL, 0);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
__setup("softlockup_panic=", softlockup_panic_setup);
|
|
|
|
|
2010-05-07 14:11:44 -07:00
|
|
|
static int __init nowatchdog_setup(char *str)
|
|
|
|
{
|
2017-09-12 12:37:17 -07:00
|
|
|
watchdog_user_enabled = 0;
|
2010-05-07 14:11:44 -07:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
__setup("nowatchdog", nowatchdog_setup);
|
|
|
|
|
|
|
|
static int __init nosoftlockup_setup(char *str)
|
|
|
|
{
|
2023-05-19 10:18:36 -07:00
|
|
|
watchdog_softlockup_user_enabled = 0;
|
2010-05-07 14:11:44 -07:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
__setup("nosoftlockup", nosoftlockup_setup);
|
2015-04-14 15:44:13 -07:00
|
|
|
|
2018-11-01 06:30:18 -07: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 12:37:04 -07:00
|
|
|
static void __lockup_detector_cleanup(void);
|
|
|
|
|
watchdog/softlockup: Low-overhead detection of interrupt storm
The following softlockup is caused by interrupt storm, but it cannot be
identified from the call tree. Because the call tree is just a snapshot
and doesn't fully capture the behavior of the CPU during the soft lockup.
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
...
Call trace:
__do_softirq+0xa0/0x37c
__irq_exit_rcu+0x108/0x140
irq_exit+0x14/0x20
__handle_domain_irq+0x84/0xe0
gic_handle_irq+0x80/0x108
el0_irq_naked+0x50/0x58
Therefore, it is necessary to report CPU utilization during the
softlockup_threshold period (report once every sample_period, for a total
of 5 reportings), like this:
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
CPU#28 Utilization every 4s during lockup:
#1: 0% system, 0% softirq, 100% hardirq, 0% idle
#2: 0% system, 0% softirq, 100% hardirq, 0% idle
#3: 0% system, 0% softirq, 100% hardirq, 0% idle
#4: 0% system, 0% softirq, 100% hardirq, 0% idle
#5: 0% system, 0% softirq, 100% hardirq, 0% idle
...
This is helpful in determining whether an interrupt storm has occurred or
in identifying the cause of the softlockup. The criteria for determination
are as follows:
a. If the hardirq utilization is high, then interrupt storm should be
considered and the root cause cannot be determined from the call tree.
b. If the softirq utilization is high, then the call might not necessarily
point at the root cause.
c. If the system utilization is high, then analyzing the root
cause from the call tree is possible in most cases.
The mechanism requires a considerable amount of global storage space
when configured for the maximum number of CPUs. Therefore, adding a
SOFTLOCKUP_DETECTOR_INTR_STORM Kconfig knob that defaults to "yes"
if the max number of CPUs is <= 128.
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240411074134.30922-5-yaoma@linux.alibaba.com
2024-04-11 00:41:33 -07:00
|
|
|
#ifdef CONFIG_SOFTLOCKUP_DETECTOR_INTR_STORM
|
|
|
|
enum stats_per_group {
|
|
|
|
STATS_SYSTEM,
|
|
|
|
STATS_SOFTIRQ,
|
|
|
|
STATS_HARDIRQ,
|
|
|
|
STATS_IDLE,
|
|
|
|
NUM_STATS_PER_GROUP,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const enum cpu_usage_stat tracked_stats[NUM_STATS_PER_GROUP] = {
|
|
|
|
CPUTIME_SYSTEM,
|
|
|
|
CPUTIME_SOFTIRQ,
|
|
|
|
CPUTIME_IRQ,
|
|
|
|
CPUTIME_IDLE,
|
|
|
|
};
|
|
|
|
|
|
|
|
static DEFINE_PER_CPU(u16, cpustat_old[NUM_STATS_PER_GROUP]);
|
|
|
|
static DEFINE_PER_CPU(u8, cpustat_util[NUM_SAMPLE_PERIODS][NUM_STATS_PER_GROUP]);
|
|
|
|
static DEFINE_PER_CPU(u8, cpustat_tail);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We don't need nanosecond resolution. A granularity of 16ms is
|
|
|
|
* sufficient for our precision, allowing us to use u16 to store
|
|
|
|
* cpustats, which will roll over roughly every ~1000 seconds.
|
|
|
|
* 2^24 ~= 16 * 10^6
|
|
|
|
*/
|
|
|
|
static u16 get_16bit_precision(u64 data_ns)
|
|
|
|
{
|
|
|
|
return data_ns >> 24LL; /* 2^24ns ~= 16.8ms */
|
|
|
|
}
|
|
|
|
|
|
|
|
static void update_cpustat(void)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
u8 util;
|
|
|
|
u16 old_stat, new_stat;
|
|
|
|
struct kernel_cpustat kcpustat;
|
|
|
|
u64 *cpustat = kcpustat.cpustat;
|
|
|
|
u8 tail = __this_cpu_read(cpustat_tail);
|
|
|
|
u16 sample_period_16 = get_16bit_precision(sample_period);
|
|
|
|
|
|
|
|
kcpustat_cpu_fetch(&kcpustat, smp_processor_id());
|
|
|
|
|
|
|
|
for (i = 0; i < NUM_STATS_PER_GROUP; i++) {
|
|
|
|
old_stat = __this_cpu_read(cpustat_old[i]);
|
|
|
|
new_stat = get_16bit_precision(cpustat[tracked_stats[i]]);
|
|
|
|
util = DIV_ROUND_UP(100 * (new_stat - old_stat), sample_period_16);
|
|
|
|
__this_cpu_write(cpustat_util[tail][i], util);
|
|
|
|
__this_cpu_write(cpustat_old[i], new_stat);
|
|
|
|
}
|
|
|
|
|
|
|
|
__this_cpu_write(cpustat_tail, (tail + 1) % NUM_SAMPLE_PERIODS);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void print_cpustat(void)
|
|
|
|
{
|
|
|
|
int i, group;
|
|
|
|
u8 tail = __this_cpu_read(cpustat_tail);
|
|
|
|
u64 sample_period_second = sample_period;
|
|
|
|
|
|
|
|
do_div(sample_period_second, NSEC_PER_SEC);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Outputting the "watchdog" prefix on every line is redundant and not
|
|
|
|
* concise, and the original alarm information is sufficient for
|
|
|
|
* positioning in logs, hence here printk() is used instead of pr_crit().
|
|
|
|
*/
|
|
|
|
printk(KERN_CRIT "CPU#%d Utilization every %llus during lockup:\n",
|
|
|
|
smp_processor_id(), sample_period_second);
|
|
|
|
|
|
|
|
for (i = 0; i < NUM_SAMPLE_PERIODS; i++) {
|
|
|
|
group = (tail + i) % NUM_SAMPLE_PERIODS;
|
|
|
|
printk(KERN_CRIT "\t#%d: %3u%% system,\t%3u%% softirq,\t"
|
|
|
|
"%3u%% hardirq,\t%3u%% idle\n", i + 1,
|
|
|
|
__this_cpu_read(cpustat_util[group][STATS_SYSTEM]),
|
|
|
|
__this_cpu_read(cpustat_util[group][STATS_SOFTIRQ]),
|
|
|
|
__this_cpu_read(cpustat_util[group][STATS_HARDIRQ]),
|
|
|
|
__this_cpu_read(cpustat_util[group][STATS_IDLE]));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
watchdog/softlockup: Report the most frequent interrupts
When the watchdog determines that the current soft lockup is due to an
interrupt storm based on CPU utilization, reporting the most frequent
interrupts could be good enough for further troubleshooting.
Below is an example of interrupt storm. The call tree does not provide
useful information, but analyzing which interrupt caused the soft lockup by
comparing the counts of interrupts during the lockup period allows to
identify the culprit.
[ 638.870231] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [swapper/9:0]
[ 638.870825] CPU#9 Utilization every 4s during lockup:
[ 638.871194] #1: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.871652] #2: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872107] #3: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872563] #4: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873018] #5: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873494] CPU#9 Detect HardIRQ Time exceeds 50%. Most frequent HardIRQs:
[ 638.873994] #1: 330945 irq#7
[ 638.874236] #2: 31 irq#82
[ 638.874493] #3: 10 irq#10
[ 638.874744] #4: 2 irq#89
[ 638.874992] #5: 1 irq#102
...
[ 638.875313] Call trace:
[ 638.875315] __do_softirq+0xa8/0x364
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20240411074134.30922-6-yaoma@linux.alibaba.com
2024-04-11 00:41:34 -07:00
|
|
|
#define HARDIRQ_PERCENT_THRESH 50
|
|
|
|
#define NUM_HARDIRQ_REPORT 5
|
|
|
|
struct irq_counts {
|
|
|
|
int irq;
|
|
|
|
u32 counts;
|
|
|
|
};
|
|
|
|
|
|
|
|
static DEFINE_PER_CPU(bool, snapshot_taken);
|
|
|
|
|
|
|
|
/* Tabulate the most frequent interrupts. */
|
|
|
|
static void tabulate_irq_count(struct irq_counts *irq_counts, int irq, u32 counts, int rank)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct irq_counts new_count = {irq, counts};
|
|
|
|
|
|
|
|
for (i = 0; i < rank; i++) {
|
|
|
|
if (counts > irq_counts[i].counts)
|
|
|
|
swap(new_count, irq_counts[i]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the hardirq time exceeds HARDIRQ_PERCENT_THRESH% of the sample_period,
|
|
|
|
* then the cause of softlockup might be interrupt storm. In this case, it
|
|
|
|
* would be useful to start interrupt counting.
|
|
|
|
*/
|
|
|
|
static bool need_counting_irqs(void)
|
|
|
|
{
|
|
|
|
u8 util;
|
|
|
|
int tail = __this_cpu_read(cpustat_tail);
|
|
|
|
|
|
|
|
tail = (tail + NUM_HARDIRQ_REPORT - 1) % NUM_HARDIRQ_REPORT;
|
|
|
|
util = __this_cpu_read(cpustat_util[tail][STATS_HARDIRQ]);
|
|
|
|
return util > HARDIRQ_PERCENT_THRESH;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void start_counting_irqs(void)
|
|
|
|
{
|
|
|
|
if (!__this_cpu_read(snapshot_taken)) {
|
|
|
|
kstat_snapshot_irqs();
|
|
|
|
__this_cpu_write(snapshot_taken, true);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void stop_counting_irqs(void)
|
|
|
|
{
|
|
|
|
__this_cpu_write(snapshot_taken, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void print_irq_counts(void)
|
|
|
|
{
|
|
|
|
unsigned int i, count;
|
|
|
|
struct irq_counts irq_counts_sorted[NUM_HARDIRQ_REPORT] = {
|
|
|
|
{-1, 0}, {-1, 0}, {-1, 0}, {-1, 0}, {-1, 0}
|
|
|
|
};
|
|
|
|
|
|
|
|
if (__this_cpu_read(snapshot_taken)) {
|
|
|
|
for_each_active_irq(i) {
|
|
|
|
count = kstat_get_irq_since_snapshot(i);
|
|
|
|
tabulate_irq_count(irq_counts_sorted, i, count, NUM_HARDIRQ_REPORT);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Outputting the "watchdog" prefix on every line is redundant and not
|
|
|
|
* concise, and the original alarm information is sufficient for
|
|
|
|
* positioning in logs, hence here printk() is used instead of pr_crit().
|
|
|
|
*/
|
|
|
|
printk(KERN_CRIT "CPU#%d Detect HardIRQ Time exceeds %d%%. Most frequent HardIRQs:\n",
|
|
|
|
smp_processor_id(), HARDIRQ_PERCENT_THRESH);
|
|
|
|
|
|
|
|
for (i = 0; i < NUM_HARDIRQ_REPORT; i++) {
|
|
|
|
if (irq_counts_sorted[i].irq == -1)
|
|
|
|
break;
|
|
|
|
|
|
|
|
printk(KERN_CRIT "\t#%u: %-10u\tirq#%d\n",
|
|
|
|
i + 1, irq_counts_sorted[i].counts,
|
|
|
|
irq_counts_sorted[i].irq);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the hardirq time is less than HARDIRQ_PERCENT_THRESH% in the last
|
|
|
|
* sample_period, then we suspect the interrupt storm might be subsiding.
|
|
|
|
*/
|
|
|
|
if (!need_counting_irqs())
|
|
|
|
stop_counting_irqs();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
watchdog/softlockup: Low-overhead detection of interrupt storm
The following softlockup is caused by interrupt storm, but it cannot be
identified from the call tree. Because the call tree is just a snapshot
and doesn't fully capture the behavior of the CPU during the soft lockup.
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
...
Call trace:
__do_softirq+0xa0/0x37c
__irq_exit_rcu+0x108/0x140
irq_exit+0x14/0x20
__handle_domain_irq+0x84/0xe0
gic_handle_irq+0x80/0x108
el0_irq_naked+0x50/0x58
Therefore, it is necessary to report CPU utilization during the
softlockup_threshold period (report once every sample_period, for a total
of 5 reportings), like this:
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
CPU#28 Utilization every 4s during lockup:
#1: 0% system, 0% softirq, 100% hardirq, 0% idle
#2: 0% system, 0% softirq, 100% hardirq, 0% idle
#3: 0% system, 0% softirq, 100% hardirq, 0% idle
#4: 0% system, 0% softirq, 100% hardirq, 0% idle
#5: 0% system, 0% softirq, 100% hardirq, 0% idle
...
This is helpful in determining whether an interrupt storm has occurred or
in identifying the cause of the softlockup. The criteria for determination
are as follows:
a. If the hardirq utilization is high, then interrupt storm should be
considered and the root cause cannot be determined from the call tree.
b. If the softirq utilization is high, then the call might not necessarily
point at the root cause.
c. If the system utilization is high, then analyzing the root
cause from the call tree is possible in most cases.
The mechanism requires a considerable amount of global storage space
when configured for the maximum number of CPUs. Therefore, adding a
SOFTLOCKUP_DETECTOR_INTR_STORM Kconfig knob that defaults to "yes"
if the max number of CPUs is <= 128.
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240411074134.30922-5-yaoma@linux.alibaba.com
2024-04-11 00:41:33 -07:00
|
|
|
static void report_cpu_status(void)
|
|
|
|
{
|
|
|
|
print_cpustat();
|
watchdog/softlockup: Report the most frequent interrupts
When the watchdog determines that the current soft lockup is due to an
interrupt storm based on CPU utilization, reporting the most frequent
interrupts could be good enough for further troubleshooting.
Below is an example of interrupt storm. The call tree does not provide
useful information, but analyzing which interrupt caused the soft lockup by
comparing the counts of interrupts during the lockup period allows to
identify the culprit.
[ 638.870231] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [swapper/9:0]
[ 638.870825] CPU#9 Utilization every 4s during lockup:
[ 638.871194] #1: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.871652] #2: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872107] #3: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872563] #4: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873018] #5: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873494] CPU#9 Detect HardIRQ Time exceeds 50%. Most frequent HardIRQs:
[ 638.873994] #1: 330945 irq#7
[ 638.874236] #2: 31 irq#82
[ 638.874493] #3: 10 irq#10
[ 638.874744] #4: 2 irq#89
[ 638.874992] #5: 1 irq#102
...
[ 638.875313] Call trace:
[ 638.875315] __do_softirq+0xa8/0x364
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20240411074134.30922-6-yaoma@linux.alibaba.com
2024-04-11 00:41:34 -07:00
|
|
|
print_irq_counts();
|
watchdog/softlockup: Low-overhead detection of interrupt storm
The following softlockup is caused by interrupt storm, but it cannot be
identified from the call tree. Because the call tree is just a snapshot
and doesn't fully capture the behavior of the CPU during the soft lockup.
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
...
Call trace:
__do_softirq+0xa0/0x37c
__irq_exit_rcu+0x108/0x140
irq_exit+0x14/0x20
__handle_domain_irq+0x84/0xe0
gic_handle_irq+0x80/0x108
el0_irq_naked+0x50/0x58
Therefore, it is necessary to report CPU utilization during the
softlockup_threshold period (report once every sample_period, for a total
of 5 reportings), like this:
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
CPU#28 Utilization every 4s during lockup:
#1: 0% system, 0% softirq, 100% hardirq, 0% idle
#2: 0% system, 0% softirq, 100% hardirq, 0% idle
#3: 0% system, 0% softirq, 100% hardirq, 0% idle
#4: 0% system, 0% softirq, 100% hardirq, 0% idle
#5: 0% system, 0% softirq, 100% hardirq, 0% idle
...
This is helpful in determining whether an interrupt storm has occurred or
in identifying the cause of the softlockup. The criteria for determination
are as follows:
a. If the hardirq utilization is high, then interrupt storm should be
considered and the root cause cannot be determined from the call tree.
b. If the softirq utilization is high, then the call might not necessarily
point at the root cause.
c. If the system utilization is high, then analyzing the root
cause from the call tree is possible in most cases.
The mechanism requires a considerable amount of global storage space
when configured for the maximum number of CPUs. Therefore, adding a
SOFTLOCKUP_DETECTOR_INTR_STORM Kconfig knob that defaults to "yes"
if the max number of CPUs is <= 128.
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240411074134.30922-5-yaoma@linux.alibaba.com
2024-04-11 00:41:33 -07:00
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline void update_cpustat(void) { }
|
|
|
|
static inline void report_cpu_status(void) { }
|
watchdog/softlockup: Report the most frequent interrupts
When the watchdog determines that the current soft lockup is due to an
interrupt storm based on CPU utilization, reporting the most frequent
interrupts could be good enough for further troubleshooting.
Below is an example of interrupt storm. The call tree does not provide
useful information, but analyzing which interrupt caused the soft lockup by
comparing the counts of interrupts during the lockup period allows to
identify the culprit.
[ 638.870231] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [swapper/9:0]
[ 638.870825] CPU#9 Utilization every 4s during lockup:
[ 638.871194] #1: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.871652] #2: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872107] #3: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872563] #4: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873018] #5: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873494] CPU#9 Detect HardIRQ Time exceeds 50%. Most frequent HardIRQs:
[ 638.873994] #1: 330945 irq#7
[ 638.874236] #2: 31 irq#82
[ 638.874493] #3: 10 irq#10
[ 638.874744] #4: 2 irq#89
[ 638.874992] #5: 1 irq#102
...
[ 638.875313] Call trace:
[ 638.875315] __do_softirq+0xa8/0x364
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20240411074134.30922-6-yaoma@linux.alibaba.com
2024-04-11 00:41:34 -07:00
|
|
|
static inline bool need_counting_irqs(void) { return false; }
|
|
|
|
static inline void start_counting_irqs(void) { }
|
|
|
|
static inline void stop_counting_irqs(void) { }
|
watchdog/softlockup: Low-overhead detection of interrupt storm
The following softlockup is caused by interrupt storm, but it cannot be
identified from the call tree. Because the call tree is just a snapshot
and doesn't fully capture the behavior of the CPU during the soft lockup.
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
...
Call trace:
__do_softirq+0xa0/0x37c
__irq_exit_rcu+0x108/0x140
irq_exit+0x14/0x20
__handle_domain_irq+0x84/0xe0
gic_handle_irq+0x80/0x108
el0_irq_naked+0x50/0x58
Therefore, it is necessary to report CPU utilization during the
softlockup_threshold period (report once every sample_period, for a total
of 5 reportings), like this:
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
CPU#28 Utilization every 4s during lockup:
#1: 0% system, 0% softirq, 100% hardirq, 0% idle
#2: 0% system, 0% softirq, 100% hardirq, 0% idle
#3: 0% system, 0% softirq, 100% hardirq, 0% idle
#4: 0% system, 0% softirq, 100% hardirq, 0% idle
#5: 0% system, 0% softirq, 100% hardirq, 0% idle
...
This is helpful in determining whether an interrupt storm has occurred or
in identifying the cause of the softlockup. The criteria for determination
are as follows:
a. If the hardirq utilization is high, then interrupt storm should be
considered and the root cause cannot be determined from the call tree.
b. If the softirq utilization is high, then the call might not necessarily
point at the root cause.
c. If the system utilization is high, then analyzing the root
cause from the call tree is possible in most cases.
The mechanism requires a considerable amount of global storage space
when configured for the maximum number of CPUs. Therefore, adding a
SOFTLOCKUP_DETECTOR_INTR_STORM Kconfig knob that defaults to "yes"
if the max number of CPUs is <= 128.
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240411074134.30922-5-yaoma@linux.alibaba.com
2024-04-11 00:41:33 -07:00
|
|
|
#endif
|
|
|
|
|
2011-05-22 22:10:23 -07: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-23 20:43:18 -07:00
|
|
|
static int get_softlockup_thresh(void)
|
2011-05-22 22:10:23 -07:00
|
|
|
{
|
|
|
|
return watchdog_thresh * 2;
|
|
|
|
}
|
2010-05-07 14:11:44 -07: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-26 19:49:44 -07:00
|
|
|
static unsigned long get_timestamp(void)
|
2010-05-07 14:11:44 -07:00
|
|
|
{
|
2015-02-12 16:01:24 -07:00
|
|
|
return running_clock() >> 30LL; /* 2^30 ~= 10^9 */
|
2010-05-07 14:11:44 -07:00
|
|
|
}
|
|
|
|
|
2012-12-17 16:59:50 -07:00
|
|
|
static void set_sample_period(void)
|
2010-05-07 14:11:44 -07:00
|
|
|
{
|
|
|
|
/*
|
2011-05-22 22:10:22 -07:00
|
|
|
* convert watchdog_thresh from seconds to ns
|
2012-02-09 15:42:22 -07: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 14:11:44 -07:00
|
|
|
*/
|
watchdog/softlockup: Low-overhead detection of interrupt storm
The following softlockup is caused by interrupt storm, but it cannot be
identified from the call tree. Because the call tree is just a snapshot
and doesn't fully capture the behavior of the CPU during the soft lockup.
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
...
Call trace:
__do_softirq+0xa0/0x37c
__irq_exit_rcu+0x108/0x140
irq_exit+0x14/0x20
__handle_domain_irq+0x84/0xe0
gic_handle_irq+0x80/0x108
el0_irq_naked+0x50/0x58
Therefore, it is necessary to report CPU utilization during the
softlockup_threshold period (report once every sample_period, for a total
of 5 reportings), like this:
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
CPU#28 Utilization every 4s during lockup:
#1: 0% system, 0% softirq, 100% hardirq, 0% idle
#2: 0% system, 0% softirq, 100% hardirq, 0% idle
#3: 0% system, 0% softirq, 100% hardirq, 0% idle
#4: 0% system, 0% softirq, 100% hardirq, 0% idle
#5: 0% system, 0% softirq, 100% hardirq, 0% idle
...
This is helpful in determining whether an interrupt storm has occurred or
in identifying the cause of the softlockup. The criteria for determination
are as follows:
a. If the hardirq utilization is high, then interrupt storm should be
considered and the root cause cannot be determined from the call tree.
b. If the softirq utilization is high, then the call might not necessarily
point at the root cause.
c. If the system utilization is high, then analyzing the root
cause from the call tree is possible in most cases.
The mechanism requires a considerable amount of global storage space
when configured for the maximum number of CPUs. Therefore, adding a
SOFTLOCKUP_DETECTOR_INTR_STORM Kconfig knob that defaults to "yes"
if the max number of CPUs is <= 128.
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240411074134.30922-5-yaoma@linux.alibaba.com
2024-04-11 00:41:33 -07:00
|
|
|
sample_period = get_softlockup_thresh() * ((u64)NSEC_PER_SEC / NUM_SAMPLE_PERIODS);
|
2017-08-15 00:50:13 -07:00
|
|
|
watchdog_update_hrtimer_threshold(sample_period);
|
2010-05-07 14:11:44 -07:00
|
|
|
}
|
|
|
|
|
2021-04-29 22:54:26 -07:00
|
|
|
static void update_report_ts(void)
|
|
|
|
{
|
|
|
|
__this_cpu_write(watchdog_report_ts, get_timestamp());
|
|
|
|
}
|
|
|
|
|
2010-05-07 14:11:44 -07:00
|
|
|
/* Commands for resetting the watchdog */
|
2021-04-29 22:54:20 -07:00
|
|
|
static void update_touch_ts(void)
|
2010-05-07 14:11:44 -07:00
|
|
|
{
|
2012-12-26 19:49:44 -07:00
|
|
|
__this_cpu_write(watchdog_touch_ts, get_timestamp());
|
2021-04-29 22:54:26 -07:00
|
|
|
update_report_ts();
|
2010-05-07 14:11:44 -07:00
|
|
|
}
|
|
|
|
|
2015-12-08 09:28:04 -07: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 08:25:07 -07:00
|
|
|
notrace void touch_softlockup_watchdog_sched(void)
|
2010-05-07 14:11:44 -07:00
|
|
|
{
|
2014-04-18 15:07:12 -07:00
|
|
|
/*
|
2021-04-29 22:54:26 -07: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 15:07:12 -07:00
|
|
|
*/
|
2021-04-29 22:54:26 -07:00
|
|
|
raw_cpu_write(watchdog_report_ts, SOFTLOCKUP_DELAY_REPORT);
|
2010-05-07 14:11:44 -07:00
|
|
|
}
|
2015-12-08 09:28:04 -07:00
|
|
|
|
2018-08-21 08:25:07 -07:00
|
|
|
notrace void touch_softlockup_watchdog(void)
|
2015-12-08 09:28:04 -07: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 09:28:04 -07:00
|
|
|
wq_watchdog_touch(raw_smp_processor_id());
|
2015-12-08 09:28:04 -07:00
|
|
|
}
|
2010-05-12 23:53:33 -07:00
|
|
|
EXPORT_SYMBOL(touch_softlockup_watchdog);
|
2010-05-07 14:11:44 -07:00
|
|
|
|
2010-05-07 14:11:45 -07:00
|
|
|
void touch_all_softlockup_watchdogs(void)
|
2010-05-07 14:11:44 -07:00
|
|
|
{
|
|
|
|
int cpu;
|
|
|
|
|
|
|
|
/*
|
2017-09-12 12:37:11 -07: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 14:11:44 -07:00
|
|
|
*/
|
2021-03-24 04:40:29 -07:00
|
|
|
for_each_cpu(cpu, &watchdog_allowed_mask) {
|
2021-04-29 22:54:26 -07:00
|
|
|
per_cpu(watchdog_report_ts, cpu) = SOFTLOCKUP_DELAY_REPORT;
|
2021-03-24 04:40:29 -07:00
|
|
|
wq_watchdog_touch(cpu);
|
|
|
|
}
|
2010-05-07 14:11:44 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
void touch_softlockup_watchdog_sync(void)
|
|
|
|
{
|
2014-08-17 10:30:34 -07:00
|
|
|
__this_cpu_write(softlockup_touch_sync, true);
|
2021-04-29 22:54:26 -07:00
|
|
|
__this_cpu_write(watchdog_report_ts, SOFTLOCKUP_DELAY_REPORT);
|
2010-05-07 14:11:44 -07:00
|
|
|
}
|
|
|
|
|
2021-05-22 17:41:59 -07:00
|
|
|
static int is_softlockup(unsigned long touch_ts,
|
|
|
|
unsigned long period_ts,
|
|
|
|
unsigned long now)
|
2010-05-07 14:11:44 -07:00
|
|
|
{
|
2023-05-19 10:18:36 -07:00
|
|
|
if ((watchdog_enabled & WATCHDOG_SOFTOCKUP_ENABLED) && watchdog_thresh) {
|
watchdog/softlockup: Report the most frequent interrupts
When the watchdog determines that the current soft lockup is due to an
interrupt storm based on CPU utilization, reporting the most frequent
interrupts could be good enough for further troubleshooting.
Below is an example of interrupt storm. The call tree does not provide
useful information, but analyzing which interrupt caused the soft lockup by
comparing the counts of interrupts during the lockup period allows to
identify the culprit.
[ 638.870231] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [swapper/9:0]
[ 638.870825] CPU#9 Utilization every 4s during lockup:
[ 638.871194] #1: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.871652] #2: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872107] #3: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872563] #4: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873018] #5: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873494] CPU#9 Detect HardIRQ Time exceeds 50%. Most frequent HardIRQs:
[ 638.873994] #1: 330945 irq#7
[ 638.874236] #2: 31 irq#82
[ 638.874493] #3: 10 irq#10
[ 638.874744] #4: 2 irq#89
[ 638.874992] #5: 1 irq#102
...
[ 638.875313] Call trace:
[ 638.875315] __do_softirq+0xa8/0x364
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20240411074134.30922-6-yaoma@linux.alibaba.com
2024-04-11 00:41:34 -07:00
|
|
|
/*
|
|
|
|
* If period_ts has not been updated during a sample_period, then
|
|
|
|
* in the subsequent few sample_periods, period_ts might also not
|
|
|
|
* be updated, which could indicate a potential softlockup. In
|
|
|
|
* this case, if we suspect the cause of the potential softlockup
|
|
|
|
* might be interrupt storm, then we need to count the interrupts
|
|
|
|
* to find which interrupt is storming.
|
|
|
|
*/
|
|
|
|
if (time_after_eq(now, period_ts + get_softlockup_thresh() / NUM_SAMPLE_PERIODS) &&
|
|
|
|
need_counting_irqs())
|
|
|
|
start_counting_irqs();
|
|
|
|
|
2015-04-14 15:44:13 -07:00
|
|
|
/* Warn about unreasonable delays. */
|
2021-04-29 22:54:26 -07:00
|
|
|
if (time_after(now, period_ts + get_softlockup_thresh()))
|
2015-04-14 15:44:13 -07:00
|
|
|
return now - touch_ts;
|
|
|
|
}
|
2010-05-07 14:11:44 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-07-12 14:35:46 -07:00
|
|
|
/* watchdog detector functions */
|
2018-07-13 03:42:08 -07:00
|
|
|
static DEFINE_PER_CPU(struct completion, softlockup_completion);
|
|
|
|
static DEFINE_PER_CPU(struct cpu_stop_work, softlockup_stop_work);
|
|
|
|
|
2018-06-07 01:52:03 -07:00
|
|
|
/*
|
2021-06-28 19:34:17 -07:00
|
|
|
* The watchdog feed function - touches the timestamp.
|
2018-06-07 01:52:03 -07: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-29 22:54:20 -07:00
|
|
|
update_touch_ts();
|
watchdog/softlockup: Report the most frequent interrupts
When the watchdog determines that the current soft lockup is due to an
interrupt storm based on CPU utilization, reporting the most frequent
interrupts could be good enough for further troubleshooting.
Below is an example of interrupt storm. The call tree does not provide
useful information, but analyzing which interrupt caused the soft lockup by
comparing the counts of interrupts during the lockup period allows to
identify the culprit.
[ 638.870231] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [swapper/9:0]
[ 638.870825] CPU#9 Utilization every 4s during lockup:
[ 638.871194] #1: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.871652] #2: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872107] #3: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.872563] #4: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873018] #5: 0% system, 0% softirq, 100% hardirq, 0% idle
[ 638.873494] CPU#9 Detect HardIRQ Time exceeds 50%. Most frequent HardIRQs:
[ 638.873994] #1: 330945 irq#7
[ 638.874236] #2: 31 irq#82
[ 638.874493] #3: 10 irq#10
[ 638.874744] #4: 2 irq#89
[ 638.874992] #5: 1 irq#102
...
[ 638.875313] Call trace:
[ 638.875315] __do_softirq+0xa8/0x364
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20240411074134.30922-6-yaoma@linux.alibaba.com
2024-04-11 00:41:34 -07:00
|
|
|
stop_counting_irqs();
|
2018-07-13 03:42:08 -07:00
|
|
|
complete(this_cpu_ptr(&softlockup_completion));
|
2018-06-07 01:52:03 -07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-05-07 14:11:44 -07:00
|
|
|
/* watchdog kicker functions */
|
|
|
|
static enum hrtimer_restart watchdog_timer_fn(struct hrtimer *hrtimer)
|
|
|
|
{
|
2021-05-22 17:41:59 -07:00
|
|
|
unsigned long touch_ts, period_ts, now;
|
2010-05-07 14:11:44 -07:00
|
|
|
struct pt_regs *regs = get_irq_regs();
|
|
|
|
int duration;
|
2014-06-23 13:22:05 -07:00
|
|
|
int softlockup_all_cpu_backtrace = sysctl_softlockup_all_cpu_backtrace;
|
2023-12-20 14:15:35 -07:00
|
|
|
unsigned long flags;
|
2010-05-07 14:11:44 -07:00
|
|
|
|
2017-09-12 12:37:05 -07:00
|
|
|
if (!watchdog_enabled)
|
2017-01-24 16:17:53 -07:00
|
|
|
return HRTIMER_NORESTART;
|
|
|
|
|
2023-05-26 18:41:36 -07:00
|
|
|
watchdog_hardlockup_kick();
|
2010-05-07 14:11:44 -07:00
|
|
|
|
|
|
|
/* kick the softlockup detector */
|
2018-07-13 03:42:08 -07: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 14:11:44 -07:00
|
|
|
|
|
|
|
/* .. and repeat */
|
2012-12-17 16:59:50 -07:00
|
|
|
hrtimer_forward_now(hrtimer, ns_to_ktime(sample_period));
|
2010-05-07 14:11:44 -07:00
|
|
|
|
2021-05-22 17:41:59 -07: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-29 22:54:36 -07:00
|
|
|
/*
|
|
|
|
* If a virtual machine is stopped by the host it can look to
|
2021-05-22 17:41:59 -07:00
|
|
|
* the watchdog like a soft lockup. This function touches the watchdog.
|
2021-04-29 22:54:36 -07:00
|
|
|
*/
|
|
|
|
kvm_check_and_clear_guest_paused();
|
2021-05-22 17:41:59 -07: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-29 22:54:36 -07:00
|
|
|
|
watchdog/softlockup: Low-overhead detection of interrupt storm
The following softlockup is caused by interrupt storm, but it cannot be
identified from the call tree. Because the call tree is just a snapshot
and doesn't fully capture the behavior of the CPU during the soft lockup.
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
...
Call trace:
__do_softirq+0xa0/0x37c
__irq_exit_rcu+0x108/0x140
irq_exit+0x14/0x20
__handle_domain_irq+0x84/0xe0
gic_handle_irq+0x80/0x108
el0_irq_naked+0x50/0x58
Therefore, it is necessary to report CPU utilization during the
softlockup_threshold period (report once every sample_period, for a total
of 5 reportings), like this:
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
CPU#28 Utilization every 4s during lockup:
#1: 0% system, 0% softirq, 100% hardirq, 0% idle
#2: 0% system, 0% softirq, 100% hardirq, 0% idle
#3: 0% system, 0% softirq, 100% hardirq, 0% idle
#4: 0% system, 0% softirq, 100% hardirq, 0% idle
#5: 0% system, 0% softirq, 100% hardirq, 0% idle
...
This is helpful in determining whether an interrupt storm has occurred or
in identifying the cause of the softlockup. The criteria for determination
are as follows:
a. If the hardirq utilization is high, then interrupt storm should be
considered and the root cause cannot be determined from the call tree.
b. If the softirq utilization is high, then the call might not necessarily
point at the root cause.
c. If the system utilization is high, then analyzing the root
cause from the call tree is possible in most cases.
The mechanism requires a considerable amount of global storage space
when configured for the maximum number of CPUs. Therefore, adding a
SOFTLOCKUP_DETECTOR_INTR_STORM Kconfig knob that defaults to "yes"
if the max number of CPUs is <= 128.
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240411074134.30922-5-yaoma@linux.alibaba.com
2024-04-11 00:41:33 -07:00
|
|
|
update_cpustat();
|
|
|
|
|
2021-04-29 22:54:36 -07:00
|
|
|
/* Reset the interval when touched by known problematic code. */
|
2021-04-29 22:54:26 -07:00
|
|
|
if (period_ts == SOFTLOCKUP_DELAY_REPORT) {
|
2010-12-08 08:22:55 -07:00
|
|
|
if (unlikely(__this_cpu_read(softlockup_touch_sync))) {
|
2010-05-07 14:11:44 -07:00
|
|
|
/*
|
|
|
|
* If the time stamp was touched atomically
|
|
|
|
* make sure the scheduler tick is up to date.
|
|
|
|
*/
|
2010-12-08 08:22:55 -07:00
|
|
|
__this_cpu_write(softlockup_touch_sync, false);
|
2010-05-07 14:11:44 -07:00
|
|
|
sched_clock_tick();
|
|
|
|
}
|
2012-03-10 12:37:28 -07:00
|
|
|
|
2021-04-29 22:54:26 -07:00
|
|
|
update_report_ts();
|
2010-05-07 14:11:44 -07:00
|
|
|
return HRTIMER_RESTART;
|
|
|
|
}
|
|
|
|
|
2021-05-22 17:41:59 -07:00
|
|
|
/* Check for a softlockup. */
|
|
|
|
touch_ts = __this_cpu_read(watchdog_touch_ts);
|
|
|
|
duration = is_softlockup(touch_ts, period_ts, now);
|
2010-05-07 14:11:44 -07:00
|
|
|
if (unlikely(duration)) {
|
2021-04-29 22:54:33 -07:00
|
|
|
/*
|
|
|
|
* Prevent multiple soft-lockup reports if one cpu is already
|
|
|
|
* engaged in dumping all cpu back traces.
|
|
|
|
*/
|
2014-06-23 13:22:05 -07:00
|
|
|
if (softlockup_all_cpu_backtrace) {
|
2021-04-29 22:54:33 -07:00
|
|
|
if (test_and_set_bit_lock(0, &soft_lockup_nmi_warn))
|
2014-06-23 13:22:05 -07:00
|
|
|
return HRTIMER_RESTART;
|
|
|
|
}
|
|
|
|
|
2021-04-29 22:54:23 -07:00
|
|
|
/* Start period for the next softlockup warning. */
|
2021-04-29 22:54:26 -07:00
|
|
|
update_report_ts();
|
2021-04-29 22:54:23 -07:00
|
|
|
|
2023-12-20 14:15:35 -07:00
|
|
|
printk_cpu_sync_get_irqsave(flags);
|
2014-08-06 16:04:03 -07:00
|
|
|
pr_emerg("BUG: soft lockup - CPU#%d stuck for %us! [%s:%d]\n",
|
2010-05-17 15:06:04 -07:00
|
|
|
smp_processor_id(), duration,
|
2010-05-07 14:11:44 -07:00
|
|
|
current->comm, task_pid_nr(current));
|
watchdog/softlockup: Low-overhead detection of interrupt storm
The following softlockup is caused by interrupt storm, but it cannot be
identified from the call tree. Because the call tree is just a snapshot
and doesn't fully capture the behavior of the CPU during the soft lockup.
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
...
Call trace:
__do_softirq+0xa0/0x37c
__irq_exit_rcu+0x108/0x140
irq_exit+0x14/0x20
__handle_domain_irq+0x84/0xe0
gic_handle_irq+0x80/0x108
el0_irq_naked+0x50/0x58
Therefore, it is necessary to report CPU utilization during the
softlockup_threshold period (report once every sample_period, for a total
of 5 reportings), like this:
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
CPU#28 Utilization every 4s during lockup:
#1: 0% system, 0% softirq, 100% hardirq, 0% idle
#2: 0% system, 0% softirq, 100% hardirq, 0% idle
#3: 0% system, 0% softirq, 100% hardirq, 0% idle
#4: 0% system, 0% softirq, 100% hardirq, 0% idle
#5: 0% system, 0% softirq, 100% hardirq, 0% idle
...
This is helpful in determining whether an interrupt storm has occurred or
in identifying the cause of the softlockup. The criteria for determination
are as follows:
a. If the hardirq utilization is high, then interrupt storm should be
considered and the root cause cannot be determined from the call tree.
b. If the softirq utilization is high, then the call might not necessarily
point at the root cause.
c. If the system utilization is high, then analyzing the root
cause from the call tree is possible in most cases.
The mechanism requires a considerable amount of global storage space
when configured for the maximum number of CPUs. Therefore, adding a
SOFTLOCKUP_DETECTOR_INTR_STORM Kconfig knob that defaults to "yes"
if the max number of CPUs is <= 128.
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Liu Song <liusong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240411074134.30922-5-yaoma@linux.alibaba.com
2024-04-11 00:41:33 -07:00
|
|
|
report_cpu_status();
|
2010-05-07 14:11:44 -07:00
|
|
|
print_modules();
|
|
|
|
print_irqtrace_events(current);
|
|
|
|
if (regs)
|
|
|
|
show_regs(regs);
|
|
|
|
else
|
|
|
|
dump_stack();
|
2023-12-20 14:15:35 -07:00
|
|
|
printk_cpu_sync_put_irqrestore(flags);
|
2010-05-07 14:11:44 -07:00
|
|
|
|
2014-06-23 13:22:05 -07:00
|
|
|
if (softlockup_all_cpu_backtrace) {
|
2023-08-04 07:00:42 -07:00
|
|
|
trigger_allbutcpu_cpu_backtrace(smp_processor_id());
|
2023-12-20 14:15:37 -07:00
|
|
|
if (!softlockup_panic)
|
|
|
|
clear_bit_unlock(0, &soft_lockup_nmi_warn);
|
2014-06-23 13:22:05 -07:00
|
|
|
}
|
|
|
|
|
2014-08-08 14:22:31 -07:00
|
|
|
add_taint(TAINT_SOFTLOCKUP, LOCKDEP_STILL_OK);
|
2010-05-07 14:11:44 -07:00
|
|
|
if (softlockup_panic)
|
|
|
|
panic("softlockup: hung tasks");
|
2021-04-29 22:54:30 -07:00
|
|
|
}
|
2010-05-07 14:11:44 -07:00
|
|
|
|
|
|
|
return HRTIMER_RESTART;
|
|
|
|
}
|
|
|
|
|
2012-07-16 03:42:38 -07:00
|
|
|
static void watchdog_enable(unsigned int cpu)
|
2010-05-07 14:11:44 -07:00
|
|
|
{
|
2017-09-12 12:37:05 -07:00
|
|
|
struct hrtimer *hrtimer = this_cpu_ptr(&watchdog_hrtimer);
|
2018-07-13 03:42:08 -07:00
|
|
|
struct completion *done = this_cpu_ptr(&softlockup_completion);
|
2010-05-07 14:11:44 -07:00
|
|
|
|
2018-06-07 01:52:03 -07:00
|
|
|
WARN_ON_ONCE(cpu != smp_processor_id());
|
|
|
|
|
2018-07-13 03:42:08 -07:00
|
|
|
init_completion(done);
|
|
|
|
complete(done);
|
|
|
|
|
2017-09-12 12:37:05 -07:00
|
|
|
/*
|
2023-05-19 10:18:36 -07:00
|
|
|
* Start the timer first to prevent the hardlockup watchdog triggering
|
2017-09-12 12:37:05 -07:00
|
|
|
* before the timer has a chance to fire.
|
|
|
|
*/
|
2019-07-26 11:30:54 -07:00
|
|
|
hrtimer_init(hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL_HARD);
|
2012-12-19 12:51:31 -07:00
|
|
|
hrtimer->function = watchdog_timer_fn;
|
2017-09-12 12:37:05 -07:00
|
|
|
hrtimer_start(hrtimer, ns_to_ktime(sample_period),
|
2019-07-26 11:30:54 -07:00
|
|
|
HRTIMER_MODE_REL_PINNED_HARD);
|
2012-12-19 12:51:31 -07:00
|
|
|
|
2017-09-12 12:37:05 -07:00
|
|
|
/* Initialize timestamp */
|
2021-04-29 22:54:20 -07:00
|
|
|
update_touch_ts();
|
2023-05-19 10:18:36 -07:00
|
|
|
/* Enable the hardlockup detector */
|
|
|
|
if (watchdog_enabled & WATCHDOG_HARDLOCKUP_ENABLED)
|
|
|
|
watchdog_hardlockup_enable(cpu);
|
2012-07-16 03:42:38 -07:00
|
|
|
}
|
2010-05-07 14:11:44 -07:00
|
|
|
|
2012-07-16 03:42:38 -07:00
|
|
|
static void watchdog_disable(unsigned int cpu)
|
|
|
|
{
|
2017-09-12 12:37:05 -07:00
|
|
|
struct hrtimer *hrtimer = this_cpu_ptr(&watchdog_hrtimer);
|
2010-05-07 14:11:44 -07:00
|
|
|
|
2018-06-07 01:52:03 -07:00
|
|
|
WARN_ON_ONCE(cpu != smp_processor_id());
|
|
|
|
|
2017-09-12 12:37:05 -07:00
|
|
|
/*
|
2023-05-19 10:18:36 -07: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 12:37:05 -07:00
|
|
|
*/
|
2023-05-19 10:18:36 -07:00
|
|
|
watchdog_hardlockup_disable(cpu);
|
2017-09-12 12:37:05 -07:00
|
|
|
hrtimer_cancel(hrtimer);
|
2018-07-13 03:42:08 -07:00
|
|
|
wait_for_completion(this_cpu_ptr(&softlockup_completion));
|
2010-05-07 14:11:44 -07:00
|
|
|
}
|
|
|
|
|
2018-06-07 01:52:03 -07:00
|
|
|
static int softlockup_stop_fn(void *data)
|
2013-06-06 06:42:53 -07:00
|
|
|
{
|
2018-06-07 01:52:03 -07:00
|
|
|
watchdog_disable(smp_processor_id());
|
|
|
|
return 0;
|
2013-06-06 06:42:53 -07:00
|
|
|
}
|
|
|
|
|
2018-06-07 01:52:03 -07:00
|
|
|
static void softlockup_stop_all(void)
|
2012-07-16 03:42:38 -07:00
|
|
|
{
|
2018-06-07 01:52:03 -07: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 03:42:38 -07:00
|
|
|
}
|
|
|
|
|
2018-06-07 01:52:03 -07:00
|
|
|
static int softlockup_start_fn(void *data)
|
2012-07-16 03:42:38 -07:00
|
|
|
{
|
2018-06-07 01:52:03 -07:00
|
|
|
watchdog_enable(smp_processor_id());
|
|
|
|
return 0;
|
2012-07-16 03:42:38 -07:00
|
|
|
}
|
2010-05-07 14:11:44 -07:00
|
|
|
|
2018-06-07 01:52:03 -07:00
|
|
|
static void softlockup_start_all(void)
|
2017-09-12 12:37:10 -07:00
|
|
|
{
|
2018-06-07 01:52:03 -07:00
|
|
|
int cpu;
|
2017-09-12 12:37:10 -07:00
|
|
|
|
2018-06-07 01:52:03 -07: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 12:37:10 -07:00
|
|
|
}
|
|
|
|
|
2018-06-07 01:52:03 -07:00
|
|
|
int lockup_detector_online_cpu(unsigned int cpu)
|
2017-09-12 12:37:10 -07:00
|
|
|
{
|
2019-03-26 14:51:02 -07:00
|
|
|
if (cpumask_test_cpu(cpu, &watchdog_allowed_mask))
|
|
|
|
watchdog_enable(cpu);
|
2018-06-07 01:52:03 -07:00
|
|
|
return 0;
|
2017-09-12 12:37:10 -07:00
|
|
|
}
|
|
|
|
|
2018-06-07 01:52:03 -07:00
|
|
|
int lockup_detector_offline_cpu(unsigned int cpu)
|
2017-09-12 12:37:10 -07:00
|
|
|
{
|
2019-03-26 14:51:02 -07:00
|
|
|
if (cpumask_test_cpu(cpu, &watchdog_allowed_mask))
|
|
|
|
watchdog_disable(cpu);
|
2018-06-07 01:52:03 -07:00
|
|
|
return 0;
|
2017-09-12 12:37:10 -07:00
|
|
|
}
|
|
|
|
|
2022-07-13 08:47:27 -07:00
|
|
|
static void __lockup_detector_reconfigure(void)
|
2017-09-12 12:37:10 -07:00
|
|
|
{
|
2017-10-03 07:37:53 -07:00
|
|
|
cpus_read_lock();
|
2023-05-19 10:18:36 -07:00
|
|
|
watchdog_hardlockup_stop();
|
2018-06-07 01:52:03 -07:00
|
|
|
|
|
|
|
softlockup_stop_all();
|
2017-09-12 12:37:10 -07:00
|
|
|
set_sample_period();
|
2017-09-12 12:37:17 -07:00
|
|
|
lockup_detector_update_enable();
|
|
|
|
if (watchdog_enabled && watchdog_thresh)
|
2018-06-07 01:52:03 -07:00
|
|
|
softlockup_start_all();
|
|
|
|
|
2023-05-19 10:18:36 -07:00
|
|
|
watchdog_hardlockup_start();
|
2017-10-03 07:37:53 -07: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 12:37:10 -07:00
|
|
|
}
|
|
|
|
|
2022-07-13 08:47:27 -07:00
|
|
|
void lockup_detector_reconfigure(void)
|
|
|
|
{
|
|
|
|
mutex_lock(&watchdog_mutex);
|
|
|
|
__lockup_detector_reconfigure();
|
|
|
|
mutex_unlock(&watchdog_mutex);
|
|
|
|
}
|
|
|
|
|
2017-09-12 12:37:10 -07:00
|
|
|
/*
|
2021-06-28 19:34:17 -07:00
|
|
|
* Create the watchdog infrastructure and configure the detector(s).
|
2017-09-12 12:37:10 -07:00
|
|
|
*/
|
2017-10-04 01:03:04 -07:00
|
|
|
static __init void lockup_detector_setup(void)
|
2017-09-12 12:37:10 -07:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If sysctl is off and watchdog got disabled on the command line,
|
|
|
|
* nothing to do here.
|
|
|
|
*/
|
2017-09-12 12:37:17 -07:00
|
|
|
lockup_detector_update_enable();
|
|
|
|
|
2017-09-12 12:37:10 -07:00
|
|
|
if (!IS_ENABLED(CONFIG_SYSCTL) &&
|
|
|
|
!(watchdog_enabled && watchdog_thresh))
|
|
|
|
return;
|
|
|
|
|
|
|
|
mutex_lock(&watchdog_mutex);
|
2022-07-13 08:47:27 -07:00
|
|
|
__lockup_detector_reconfigure();
|
2018-06-07 01:52:03 -07:00
|
|
|
softlockup_initialized = true;
|
2017-09-12 12:37:10 -07:00
|
|
|
mutex_unlock(&watchdog_mutex);
|
|
|
|
}
|
|
|
|
|
2017-09-12 12:37:06 -07:00
|
|
|
#else /* CONFIG_SOFTLOCKUP_DETECTOR */
|
2022-07-13 08:47:27 -07:00
|
|
|
static void __lockup_detector_reconfigure(void)
|
2017-09-12 12:37:16 -07:00
|
|
|
{
|
2017-10-03 07:37:53 -07:00
|
|
|
cpus_read_lock();
|
2023-05-19 10:18:36 -07:00
|
|
|
watchdog_hardlockup_stop();
|
2017-09-12 12:37:17 -07:00
|
|
|
lockup_detector_update_enable();
|
2023-05-19 10:18:36 -07:00
|
|
|
watchdog_hardlockup_start();
|
2017-10-03 07:37:53 -07:00
|
|
|
cpus_read_unlock();
|
2017-09-12 12:37:16 -07:00
|
|
|
}
|
2022-07-13 08:47:27 -07:00
|
|
|
void lockup_detector_reconfigure(void)
|
|
|
|
{
|
|
|
|
__lockup_detector_reconfigure();
|
|
|
|
}
|
2017-10-04 01:03:04 -07:00
|
|
|
static inline void lockup_detector_setup(void)
|
2017-10-03 07:39:02 -07:00
|
|
|
{
|
2022-07-13 08:47:27 -07:00
|
|
|
__lockup_detector_reconfigure();
|
2017-10-03 07:39:02 -07:00
|
|
|
}
|
2017-09-12 12:37:06 -07:00
|
|
|
#endif /* !CONFIG_SOFTLOCKUP_DETECTOR */
|
2017-07-12 14:35:46 -07:00
|
|
|
|
2017-09-12 12:37:04 -07: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 12:36:57 -07: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-05 19:44:30 -07:00
|
|
|
#ifdef CONFIG_SYSCTL
|
|
|
|
|
2021-06-28 19:34:17 -07:00
|
|
|
/* Propagate any changes to the watchdog infrastructure */
|
2017-09-12 12:37:11 -07:00
|
|
|
static void proc_watchdog_update(void)
|
2015-04-14 15:43:58 -07:00
|
|
|
{
|
2017-09-12 12:37:12 -07:00
|
|
|
/* Remove impossible cpus to keep sysctl output clean. */
|
|
|
|
cpumask_and(&watchdog_cpumask, &watchdog_cpumask, cpu_possible_mask);
|
2022-07-13 08:47:27 -07:00
|
|
|
__lockup_detector_reconfigure();
|
2015-04-14 15:43:58 -07:00
|
|
|
}
|
|
|
|
|
2015-04-14 15:44:05 -07:00
|
|
|
/*
|
|
|
|
* common function for watchdog, nmi_watchdog and soft_watchdog parameter
|
|
|
|
*
|
2023-05-19 10:18:36 -07: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 15:44:05 -07:00
|
|
|
*/
|
sysctl: treewide: constify the ctl_table argument of proc_handlers
const qualify the struct ctl_table argument in the proc_handler function
signatures. This is a prerequisite to moving the static ctl_table
structs into .rodata data which will ensure that proc_handler function
pointers cannot be modified.
This patch has been generated by the following coccinelle script:
```
virtual patch
@r1@
identifier ctl, write, buffer, lenp, ppos;
identifier func !~ "appldata_(timer|interval)_handler|sched_(rt|rr)_handler|rds_tcp_skbuf_handler|proc_sctp_do_(hmac_alg|rto_min|rto_max|udp_port|alpha_beta|auth|probe_interval)";
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int write, void *buffer, size_t *lenp, loff_t *ppos);
@r2@
identifier func, ctl, write, buffer, lenp, ppos;
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int write, void *buffer, size_t *lenp, loff_t *ppos)
{ ... }
@r3@
identifier func;
@@
int func(
- struct ctl_table *
+ const struct ctl_table *
,int , void *, size_t *, loff_t *);
@r4@
identifier func, ctl;
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int , void *, size_t *, loff_t *);
@r5@
identifier func, write, buffer, lenp, ppos;
@@
int func(
- struct ctl_table *
+ const struct ctl_table *
,int write, void *buffer, size_t *lenp, loff_t *ppos);
```
* Code formatting was adjusted in xfs_sysctl.c to comply with code
conventions. The xfs_stats_clear_proc_handler,
xfs_panic_mask_proc_handler and xfs_deprecated_dointvec_minmax where
adjusted.
* The ctl_table argument in proc_watchdog_common was const qualified.
This is called from a proc_handler itself and is calling back into
another proc_handler, making it necessary to change it as part of the
proc_handler migration.
Co-developed-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Co-developed-by: Joel Granados <j.granados@samsung.com>
Signed-off-by: Joel Granados <j.granados@samsung.com>
2024-07-24 11:59:29 -07:00
|
|
|
static int proc_watchdog_common(int which, const struct ctl_table *table, int write,
|
2020-04-23 23:43:38 -07:00
|
|
|
void *buffer, size_t *lenp, loff_t *ppos)
|
2015-04-14 15:44:05 -07:00
|
|
|
{
|
2017-09-12 12:37:17 -07:00
|
|
|
int err, old, *param = table->data;
|
2015-04-14 15:44:05 -07:00
|
|
|
|
2017-09-12 12:37:01 -07:00
|
|
|
mutex_lock(&watchdog_mutex);
|
2015-04-14 15:44:05 -07:00
|
|
|
|
|
|
|
if (!write) {
|
2017-09-12 12:37:17 -07:00
|
|
|
/*
|
|
|
|
* On read synchronize the userspace interface. This is a
|
|
|
|
* racy snapshot.
|
|
|
|
*/
|
|
|
|
*param = (watchdog_enabled & which) != 0;
|
2015-04-14 15:44:05 -07:00
|
|
|
err = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
|
|
|
|
} else {
|
2017-09-12 12:37:17 -07:00
|
|
|
old = READ_ONCE(*param);
|
2015-04-14 15:44:05 -07:00
|
|
|
err = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
|
2017-09-12 12:37:17 -07:00
|
|
|
if (!err && old != READ_ONCE(*param))
|
2017-09-12 12:37:11 -07:00
|
|
|
proc_watchdog_update();
|
2015-04-14 15:44:05 -07:00
|
|
|
}
|
2017-09-12 12:37:01 -07:00
|
|
|
mutex_unlock(&watchdog_mutex);
|
2015-04-14 15:44:05 -07:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2015-04-14 15:44:08 -07:00
|
|
|
/*
|
|
|
|
* /proc/sys/kernel/watchdog
|
|
|
|
*/
|
sysctl: treewide: constify the ctl_table argument of proc_handlers
const qualify the struct ctl_table argument in the proc_handler function
signatures. This is a prerequisite to moving the static ctl_table
structs into .rodata data which will ensure that proc_handler function
pointers cannot be modified.
This patch has been generated by the following coccinelle script:
```
virtual patch
@r1@
identifier ctl, write, buffer, lenp, ppos;
identifier func !~ "appldata_(timer|interval)_handler|sched_(rt|rr)_handler|rds_tcp_skbuf_handler|proc_sctp_do_(hmac_alg|rto_min|rto_max|udp_port|alpha_beta|auth|probe_interval)";
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int write, void *buffer, size_t *lenp, loff_t *ppos);
@r2@
identifier func, ctl, write, buffer, lenp, ppos;
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int write, void *buffer, size_t *lenp, loff_t *ppos)
{ ... }
@r3@
identifier func;
@@
int func(
- struct ctl_table *
+ const struct ctl_table *
,int , void *, size_t *, loff_t *);
@r4@
identifier func, ctl;
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int , void *, size_t *, loff_t *);
@r5@
identifier func, write, buffer, lenp, ppos;
@@
int func(
- struct ctl_table *
+ const struct ctl_table *
,int write, void *buffer, size_t *lenp, loff_t *ppos);
```
* Code formatting was adjusted in xfs_sysctl.c to comply with code
conventions. The xfs_stats_clear_proc_handler,
xfs_panic_mask_proc_handler and xfs_deprecated_dointvec_minmax where
adjusted.
* The ctl_table argument in proc_watchdog_common was const qualified.
This is called from a proc_handler itself and is calling back into
another proc_handler, making it necessary to change it as part of the
proc_handler migration.
Co-developed-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Co-developed-by: Joel Granados <j.granados@samsung.com>
Signed-off-by: Joel Granados <j.granados@samsung.com>
2024-07-24 11:59:29 -07:00
|
|
|
static int proc_watchdog(const struct ctl_table *table, int write,
|
2024-03-05 23:49:16 -07:00
|
|
|
void *buffer, size_t *lenp, loff_t *ppos)
|
2015-04-14 15:44:08 -07:00
|
|
|
{
|
2023-05-19 10:18:36 -07:00
|
|
|
return proc_watchdog_common(WATCHDOG_HARDLOCKUP_ENABLED |
|
|
|
|
WATCHDOG_SOFTOCKUP_ENABLED,
|
2015-04-14 15:44:08 -07:00
|
|
|
table, write, buffer, lenp, ppos);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* /proc/sys/kernel/nmi_watchdog
|
2010-05-07 14:11:44 -07:00
|
|
|
*/
|
sysctl: treewide: constify the ctl_table argument of proc_handlers
const qualify the struct ctl_table argument in the proc_handler function
signatures. This is a prerequisite to moving the static ctl_table
structs into .rodata data which will ensure that proc_handler function
pointers cannot be modified.
This patch has been generated by the following coccinelle script:
```
virtual patch
@r1@
identifier ctl, write, buffer, lenp, ppos;
identifier func !~ "appldata_(timer|interval)_handler|sched_(rt|rr)_handler|rds_tcp_skbuf_handler|proc_sctp_do_(hmac_alg|rto_min|rto_max|udp_port|alpha_beta|auth|probe_interval)";
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int write, void *buffer, size_t *lenp, loff_t *ppos);
@r2@
identifier func, ctl, write, buffer, lenp, ppos;
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int write, void *buffer, size_t *lenp, loff_t *ppos)
{ ... }
@r3@
identifier func;
@@
int func(
- struct ctl_table *
+ const struct ctl_table *
,int , void *, size_t *, loff_t *);
@r4@
identifier func, ctl;
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int , void *, size_t *, loff_t *);
@r5@
identifier func, write, buffer, lenp, ppos;
@@
int func(
- struct ctl_table *
+ const struct ctl_table *
,int write, void *buffer, size_t *lenp, loff_t *ppos);
```
* Code formatting was adjusted in xfs_sysctl.c to comply with code
conventions. The xfs_stats_clear_proc_handler,
xfs_panic_mask_proc_handler and xfs_deprecated_dointvec_minmax where
adjusted.
* The ctl_table argument in proc_watchdog_common was const qualified.
This is called from a proc_handler itself and is calling back into
another proc_handler, making it necessary to change it as part of the
proc_handler migration.
Co-developed-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Co-developed-by: Joel Granados <j.granados@samsung.com>
Signed-off-by: Joel Granados <j.granados@samsung.com>
2024-07-24 11:59:29 -07:00
|
|
|
static int proc_nmi_watchdog(const struct ctl_table *table, int write,
|
2024-03-05 23:49:16 -07:00
|
|
|
void *buffer, size_t *lenp, loff_t *ppos)
|
2015-04-14 15:44:08 -07:00
|
|
|
{
|
2023-05-19 10:18:36 -07:00
|
|
|
if (!watchdog_hardlockup_available && write)
|
2017-09-12 12:37:19 -07:00
|
|
|
return -ENOTSUPP;
|
2023-05-19 10:18:36 -07:00
|
|
|
return proc_watchdog_common(WATCHDOG_HARDLOCKUP_ENABLED,
|
2015-04-14 15:44:08 -07:00
|
|
|
table, write, buffer, lenp, ppos);
|
|
|
|
}
|
|
|
|
|
2024-03-05 23:49:16 -07:00
|
|
|
#ifdef CONFIG_SOFTLOCKUP_DETECTOR
|
2015-04-14 15:44:08 -07:00
|
|
|
/*
|
|
|
|
* /proc/sys/kernel/soft_watchdog
|
|
|
|
*/
|
sysctl: treewide: constify the ctl_table argument of proc_handlers
const qualify the struct ctl_table argument in the proc_handler function
signatures. This is a prerequisite to moving the static ctl_table
structs into .rodata data which will ensure that proc_handler function
pointers cannot be modified.
This patch has been generated by the following coccinelle script:
```
virtual patch
@r1@
identifier ctl, write, buffer, lenp, ppos;
identifier func !~ "appldata_(timer|interval)_handler|sched_(rt|rr)_handler|rds_tcp_skbuf_handler|proc_sctp_do_(hmac_alg|rto_min|rto_max|udp_port|alpha_beta|auth|probe_interval)";
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int write, void *buffer, size_t *lenp, loff_t *ppos);
@r2@
identifier func, ctl, write, buffer, lenp, ppos;
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int write, void *buffer, size_t *lenp, loff_t *ppos)
{ ... }
@r3@
identifier func;
@@
int func(
- struct ctl_table *
+ const struct ctl_table *
,int , void *, size_t *, loff_t *);
@r4@
identifier func, ctl;
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int , void *, size_t *, loff_t *);
@r5@
identifier func, write, buffer, lenp, ppos;
@@
int func(
- struct ctl_table *
+ const struct ctl_table *
,int write, void *buffer, size_t *lenp, loff_t *ppos);
```
* Code formatting was adjusted in xfs_sysctl.c to comply with code
conventions. The xfs_stats_clear_proc_handler,
xfs_panic_mask_proc_handler and xfs_deprecated_dointvec_minmax where
adjusted.
* The ctl_table argument in proc_watchdog_common was const qualified.
This is called from a proc_handler itself and is calling back into
another proc_handler, making it necessary to change it as part of the
proc_handler migration.
Co-developed-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Co-developed-by: Joel Granados <j.granados@samsung.com>
Signed-off-by: Joel Granados <j.granados@samsung.com>
2024-07-24 11:59:29 -07:00
|
|
|
static int proc_soft_watchdog(const struct ctl_table *table, int write,
|
2024-03-05 23:49:16 -07:00
|
|
|
void *buffer, size_t *lenp, loff_t *ppos)
|
2015-04-14 15:44:08 -07:00
|
|
|
{
|
2023-05-19 10:18:36 -07:00
|
|
|
return proc_watchdog_common(WATCHDOG_SOFTOCKUP_ENABLED,
|
2015-04-14 15:44:08 -07:00
|
|
|
table, write, buffer, lenp, ppos);
|
|
|
|
}
|
2024-03-05 23:49:16 -07:00
|
|
|
#endif
|
2010-05-07 14:11:44 -07:00
|
|
|
|
2015-04-14 15:44:08 -07:00
|
|
|
/*
|
|
|
|
* /proc/sys/kernel/watchdog_thresh
|
|
|
|
*/
|
sysctl: treewide: constify the ctl_table argument of proc_handlers
const qualify the struct ctl_table argument in the proc_handler function
signatures. This is a prerequisite to moving the static ctl_table
structs into .rodata data which will ensure that proc_handler function
pointers cannot be modified.
This patch has been generated by the following coccinelle script:
```
virtual patch
@r1@
identifier ctl, write, buffer, lenp, ppos;
identifier func !~ "appldata_(timer|interval)_handler|sched_(rt|rr)_handler|rds_tcp_skbuf_handler|proc_sctp_do_(hmac_alg|rto_min|rto_max|udp_port|alpha_beta|auth|probe_interval)";
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int write, void *buffer, size_t *lenp, loff_t *ppos);
@r2@
identifier func, ctl, write, buffer, lenp, ppos;
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int write, void *buffer, size_t *lenp, loff_t *ppos)
{ ... }
@r3@
identifier func;
@@
int func(
- struct ctl_table *
+ const struct ctl_table *
,int , void *, size_t *, loff_t *);
@r4@
identifier func, ctl;
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int , void *, size_t *, loff_t *);
@r5@
identifier func, write, buffer, lenp, ppos;
@@
int func(
- struct ctl_table *
+ const struct ctl_table *
,int write, void *buffer, size_t *lenp, loff_t *ppos);
```
* Code formatting was adjusted in xfs_sysctl.c to comply with code
conventions. The xfs_stats_clear_proc_handler,
xfs_panic_mask_proc_handler and xfs_deprecated_dointvec_minmax where
adjusted.
* The ctl_table argument in proc_watchdog_common was const qualified.
This is called from a proc_handler itself and is calling back into
another proc_handler, making it necessary to change it as part of the
proc_handler migration.
Co-developed-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Co-developed-by: Joel Granados <j.granados@samsung.com>
Signed-off-by: Joel Granados <j.granados@samsung.com>
2024-07-24 11:59:29 -07:00
|
|
|
static int proc_watchdog_thresh(const struct ctl_table *table, int write,
|
2024-03-05 23:49:16 -07:00
|
|
|
void *buffer, size_t *lenp, loff_t *ppos)
|
2010-05-07 14:11:44 -07:00
|
|
|
{
|
2017-09-12 12:37:11 -07:00
|
|
|
int err, old;
|
2010-05-07 14:11:44 -07:00
|
|
|
|
2017-09-12 12:37:01 -07:00
|
|
|
mutex_lock(&watchdog_mutex);
|
2012-07-16 03:42:38 -07:00
|
|
|
|
2017-09-12 12:37:11 -07:00
|
|
|
old = READ_ONCE(watchdog_thresh);
|
2013-06-06 06:42:53 -07:00
|
|
|
err = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
|
2015-04-14 15:44:08 -07:00
|
|
|
|
2017-09-12 12:37:11 -07:00
|
|
|
if (!err && write && old != READ_ONCE(watchdog_thresh))
|
|
|
|
proc_watchdog_update();
|
2011-05-22 22:10:21 -07:00
|
|
|
|
2017-09-12 12:37:01 -07:00
|
|
|
mutex_unlock(&watchdog_mutex);
|
2013-06-06 06:42:53 -07:00
|
|
|
return err;
|
2010-05-07 14:11:44 -07:00
|
|
|
}
|
2015-06-24 16:55:45 -07: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.
|
|
|
|
*/
|
sysctl: treewide: constify the ctl_table argument of proc_handlers
const qualify the struct ctl_table argument in the proc_handler function
signatures. This is a prerequisite to moving the static ctl_table
structs into .rodata data which will ensure that proc_handler function
pointers cannot be modified.
This patch has been generated by the following coccinelle script:
```
virtual patch
@r1@
identifier ctl, write, buffer, lenp, ppos;
identifier func !~ "appldata_(timer|interval)_handler|sched_(rt|rr)_handler|rds_tcp_skbuf_handler|proc_sctp_do_(hmac_alg|rto_min|rto_max|udp_port|alpha_beta|auth|probe_interval)";
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int write, void *buffer, size_t *lenp, loff_t *ppos);
@r2@
identifier func, ctl, write, buffer, lenp, ppos;
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int write, void *buffer, size_t *lenp, loff_t *ppos)
{ ... }
@r3@
identifier func;
@@
int func(
- struct ctl_table *
+ const struct ctl_table *
,int , void *, size_t *, loff_t *);
@r4@
identifier func, ctl;
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int , void *, size_t *, loff_t *);
@r5@
identifier func, write, buffer, lenp, ppos;
@@
int func(
- struct ctl_table *
+ const struct ctl_table *
,int write, void *buffer, size_t *lenp, loff_t *ppos);
```
* Code formatting was adjusted in xfs_sysctl.c to comply with code
conventions. The xfs_stats_clear_proc_handler,
xfs_panic_mask_proc_handler and xfs_deprecated_dointvec_minmax where
adjusted.
* The ctl_table argument in proc_watchdog_common was const qualified.
This is called from a proc_handler itself and is calling back into
another proc_handler, making it necessary to change it as part of the
proc_handler migration.
Co-developed-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Co-developed-by: Joel Granados <j.granados@samsung.com>
Signed-off-by: Joel Granados <j.granados@samsung.com>
2024-07-24 11:59:29 -07:00
|
|
|
static int proc_watchdog_cpumask(const struct ctl_table *table, int write,
|
2024-03-05 23:49:16 -07:00
|
|
|
void *buffer, size_t *lenp, loff_t *ppos)
|
2015-06-24 16:55:45 -07:00
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2017-09-12 12:37:01 -07:00
|
|
|
mutex_lock(&watchdog_mutex);
|
2015-09-04 15:45:18 -07:00
|
|
|
|
2015-06-24 16:55:45 -07:00
|
|
|
err = proc_do_large_bitmap(table, write, buffer, lenp, ppos);
|
2017-09-12 12:37:08 -07:00
|
|
|
if (!err && write)
|
2017-09-12 12:37:12 -07:00
|
|
|
proc_watchdog_update();
|
2017-09-12 12:36:59 -07:00
|
|
|
|
2017-09-12 12:37:01 -07:00
|
|
|
mutex_unlock(&watchdog_mutex);
|
2015-06-24 16:55:45 -07:00
|
|
|
return err;
|
|
|
|
}
|
2022-01-21 23:11:05 -07: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 10:18:36 -07:00
|
|
|
.data = &watchdog_softlockup_user_enabled,
|
2022-01-21 23:11:05 -07: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-26 18:41:31 -07: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-21 23:11:05 -07:00
|
|
|
static void __init watchdog_sysctl_init(void)
|
|
|
|
{
|
|
|
|
register_sysctl_init("kernel", watchdog_sysctls);
|
2023-05-26 18:41:31 -07:00
|
|
|
|
|
|
|
if (watchdog_hardlockup_available)
|
|
|
|
watchdog_hardlockup_sysctl[0].mode = 0644;
|
|
|
|
register_sysctl_init("kernel", watchdog_hardlockup_sysctl);
|
2022-01-21 23:11:05 -07:00
|
|
|
}
|
2023-05-26 18:41:31 -07:00
|
|
|
|
2022-01-21 23:11:05 -07:00
|
|
|
#else
|
|
|
|
#define watchdog_sysctl_init() do { } while (0)
|
2010-05-07 14:11:44 -07:00
|
|
|
#endif /* CONFIG_SYSCTL */
|
|
|
|
|
2023-05-19 10:18:40 -07: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) {
|
2024-08-02 08:16:21 -07:00
|
|
|
if (ret == -ENODEV)
|
|
|
|
pr_info("NMI not fully supported\n");
|
|
|
|
else
|
|
|
|
pr_info("Delayed init of the lockup detector failed: %d\n", ret);
|
2023-05-19 10:18:40 -07:00
|
|
|
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-26 18:41:31 -07:00
|
|
|
watchdog_sysctl_init();
|
|
|
|
|
2023-05-19 10:18:40 -07:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
}
|
|
|
|
late_initcall_sync(lockup_detector_check);
|
|
|
|
|
2010-11-25 10:38:29 -07:00
|
|
|
void __init lockup_detector_init(void)
|
2010-05-07 14:11:44 -07:00
|
|
|
{
|
2017-10-26 19:42:29 -07:00
|
|
|
if (tick_nohz_full_enabled())
|
2015-09-04 15:45:09 -07:00
|
|
|
pr_info("Disabling watchdog on nohz_full cores by default\n");
|
2017-10-26 19:42:29 -07:00
|
|
|
|
2017-10-26 19:42:35 -07:00
|
|
|
cpumask_copy(&watchdog_cpumask,
|
2022-02-07 08:59:06 -07:00
|
|
|
housekeeping_cpumask(HK_TYPE_TIMER));
|
2015-06-24 16:55:45 -07:00
|
|
|
|
2023-05-19 10:18:36 -07:00
|
|
|
if (!watchdog_hardlockup_probe())
|
|
|
|
watchdog_hardlockup_available = true;
|
2023-05-19 10:18:40 -07:00
|
|
|
else
|
|
|
|
allow_lockup_detector_init_retry = true;
|
|
|
|
|
2017-10-04 01:03:04 -07:00
|
|
|
lockup_detector_setup();
|
2010-05-07 14:11:44 -07:00
|
|
|
}
|