Commit 1717f2096b ("panic, x86: Fix re-entrance problem due to panic
on NMI") introduced nmi_panic() which prevents concurrent and recursive
execution of panic(). It also saves registers for the crash dump on x86
by later commit 58c5661f21 ("panic, x86: Allow CPUs to save registers
even if looping in NMI context").
hpwdt driver can call panic() from NMI handler, so replace it with
nmi_panic(). Also, do some cleanups.
Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Cc: Thomas Mingarelli <thomas.mingarelli@hpe.com>
Cc: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull 'objtool' stack frame validation from Ingo Molnar:
"This tree adds a new kernel build-time object file validation feature
(ONFIG_STACK_VALIDATION=y): kernel stack frame correctness validation.
It was written by and is maintained by Josh Poimboeuf.
The motivation: there's a category of hard to find kernel bugs, most
of them in assembly code (but also occasionally in C code), that
degrades the quality of kernel stack dumps/backtraces. These bugs are
hard to detect at the source code level. Such bugs result in
incorrect/incomplete backtraces most of time - but can also in some
rare cases result in crashes or other undefined behavior.
The build time correctness checking is done via the new 'objtool'
user-space utility that was written for this purpose and which is
hosted in the kernel repository in tools/objtool/. The tool's (very
simple) UI and source code design is shaped after Git and perf and
shares quite a bit of infrastructure with tools/perf (which tooling
infrastructure sharing effort got merged via perf and is already
upstream). Objtool follows the well-known kernel coding style.
Objtool does not try to check .c or .S files, it instead analyzes the
resulting .o generated machine code from first principles: it decodes
the instruction stream and interprets it. (Right now objtool supports
the x86-64 architecture.)
From tools/objtool/Documentation/stack-validation.txt:
"The kernel CONFIG_STACK_VALIDATION option enables a host tool named
objtool which runs at compile time. It has a "check" subcommand
which analyzes every .o file and ensures the validity of its stack
metadata. It enforces a set of rules on asm code and C inline
assembly code so that stack traces can be reliable.
Currently it only checks frame pointer usage, but there are plans to
add CFI validation for C files and CFI generation for asm files.
For each function, it recursively follows all possible code paths
and validates the correct frame pointer state at each instruction.
It also follows code paths involving special sections, like
.altinstructions, __jump_table, and __ex_table, which can add
alternative execution paths to a given instruction (or set of
instructions). Similarly, it knows how to follow switch statements,
for which gcc sometimes uses jump tables."
When this new kernel option is enabled (it's disabled by default), the
tool, if it finds any suspicious assembly code pattern, outputs
warnings in compiler warning format:
warning: objtool: rtlwifi_rate_mapping()+0x2e7: frame pointer state mismatch
warning: objtool: cik_tiling_mode_table_init()+0x6ce: call without frame pointer save/setup
warning: objtool:__schedule()+0x3c0: duplicate frame pointer save
warning: objtool:__schedule()+0x3fd: sibling call from callable instruction with changed frame pointer
... so that scripts that pick up compiler warnings will notice them.
All known warnings triggered by the tool are fixed by the tree, most
of the commits in fact prepare the kernel to be warning-free. Most of
them are bugfixes or cleanups that stand on their own, but there are
also some annotations of 'special' stack frames for justified cases
such entries to JIT-ed code (BPF) or really special boot time code.
There are two other long-term motivations behind this tool as well:
- To improve the quality and reliability of kernel stack frames, so
that they can be used for optimized live patching.
- To create independent infrastructure to check the correctness of
CFI stack frames at build time. CFI debuginfo is notoriously
unreliable and we cannot use it in the kernel as-is without extra
checking done both on the kernel side and on the build side.
The quality of kernel stack frames matters to debuggability as well,
so IMO we can merge this without having to consider the live patching
or CFI debuginfo angle"
* 'core-objtool-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (52 commits)
objtool: Only print one warning per function
objtool: Add several performance improvements
tools: Copy hashtable.h into tools directory
objtool: Fix false positive warnings for functions with multiple switch statements
objtool: Rename some variables and functions
objtool: Remove superflous INIT_LIST_HEAD
objtool: Add helper macros for traversing instructions
objtool: Fix false positive warnings related to sibling calls
objtool: Compile with debugging symbols
objtool: Detect infinite recursion
objtool: Prevent infinite recursion in noreturn detection
objtool: Detect and warn if libelf is missing and don't break the build
tools: Support relative directory path for 'O='
objtool: Support CROSS_COMPILE
x86/asm/decoder: Use explicitly signed chars
objtool: Enable stack metadata validation on 64-bit x86
objtool: Add CONFIG_STACK_VALIDATION option
objtool: Add tool to perform compile-time stack metadata validation
x86/kprobes: Mark kretprobe_trampoline() stack frame as non-standard
sched: Always inline context_switch()
...
Pull watchdog updates from Wim Van Sebroeck:
- new drivers for: NI 903x/913x watchdog driver, WinSystems EBC-C384
watchdog timer and ARM SBSA watchdog driver
- Support for NCT6102D devices
- Improvements of the generic watchdog framework (improve restart
handler, make set_timeout optional, introduce infrastructure
triggered keepalives, ...
- improvements on the pnx4008 watchdog driver
- several smaller fixes and improvements
* git://www.linux-watchdog.org/linux-watchdog: (28 commits)
watchdog: Ensure that wdd is not dereferenced if NULL
watchdog: imx2: Convert to use infrastructure triggered keepalives
watchdog: dw_wdt: Convert to use watchdog infrastructure
watchdog: Add support for minimum time between heartbeats
watchdog: Make stop function optional
watchdog: Introduce WDOG_HW_RUNNING flag
watchdog: Introduce hardware maximum heartbeat in watchdog core
watchdog: Make set_timeout function optional
arm: lpc32xx: remove restart handler
arm: lpc32xx: phy3250 remove restart hook
watchdog: pnx4008: restart: support "cmd" from userspace
watchdog: pnx4008: add support for soft reset
watchdog: pnx4008: add restart handler
watchdog: pnx4008: update logging during power-on
watchdog: tangox_wdt: test clock rate to avoid division by 0
watchdog: atlas7_wdt: test clock rate to avoid division by 0
watchdog: s3c2410_wdt: Add max and min timeout values
Watchdog: introduce ARM SBSA watchdog driver
Documentation: add sbsa-gwdt driver documentation
watchdog: Add watchdog timer support for the WinSystems EBC-C384
...
Smatch rightfully complains that wdd is dereferenced in the watchdog
release function after being checked for NULL. Also make sure that it
is not accessed outside mutex protection to avoid use-after-free problems.
Fixes: e6c71e84e4c0 ("watchdog: Introduce WDOG_HW_RUNNING flag")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
The watchdog infrastructure now supports handling watchdog keepalive
if the watchdog is running while the watchdog device is closed.
Convert the driver to use this infrastructure.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Convert driver to use watchdog infrastructure. This includes
infrastructure support to handle watchdog keepalive if the watchdog
is running while the watchdog device is closed.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Some watchdogs require a minimum time between heartbeats.
Examples are the watchdogs in DA9062 and AT91SAM9x.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Not all hardware watchdogs can be stopped. The driver for
such watchdogs would typically only set the WATCHDOG_HW_RUNNING
flag in its stop function. Make the stop function optional and set
WATCHDOG_HW_RUNNING in the watchdog core if it is not provided.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
The WDOG_HW_RUNNING flag is expected to be set by watchdog drivers if
the hardware watchdog is running. If the flag is set, the watchdog
subsystem will ping the watchdog even if the watchdog device is closed.
The watchdog driver stop function is now optional and may be omitted
if the watchdog can not be stopped. If stopping the watchdog is not
possible but the driver implements a stop function, it is responsible
to set the WDOG_HW_RUNNING flag in its stop function.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Introduce an optional hardware maximum heartbeat in the watchdog core.
The hardware maximum heartbeat can be lower than the maximum timeout.
Drivers can set the maximum hardware heartbeat value in the watchdog data
structure. If the configured timeout exceeds the maximum hardware heartbeat,
the watchdog core enables a timer function to assist sending keepalive
requests to the watchdog driver.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
For some watchdogs, the watchdog driver handles timeout changes without
explicitly setting any registers. In this situation, the watchdog driver
might only set the 'timeout' variable but do nothing else.
This can as well be handled by the infrastructure, so make the set_timeout
callback optional. If WDIOF_SETTIMEOUT is configured but the .set_timeout
callback is not available, update the timeout variable in the
infrastructure code.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Added support to verify if a "cmd" is passed from the userspace program rebooting the system;
- if a valid "cmd" is available, handle it;
- If the received "cmd" is not supported, use the default reboot mode.
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Add support for explicit soft reset using the reboot mode.
The default reboot mode behavior is unchanged;
you can overwrite the default reboot type in the board specific file
"DT_MACHINE_START" definition using the "reboot_mode" parameter.
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Add restart handler capability to the driver;
the restart handler implementation was taken from
"mach-lpc32xx" ("lpc23xx_restart" function).
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
There is no need to add the driver name in the text to display
on the console during the power-on:
pnx4008-watchdog 4003c000.watchdog: PNX4008 Watchdog Timer: heartbeat 19 sec
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
The clk API may return 0 on clk_get_rate, so we should check the result before
using it as a divisor. For this, refactor the code to use a central
error path.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
The clk API may return 0 on clk_get_rate, so we should check the result before
using it as a divisor.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
The watchdog maximum timeout value is determined by the number of bits
for the interval timer counter, its source clock frequency, the number
of bits of the prescaler and maximum divider value.
This can be calculated with the following equation:
max_timeout = counter / (freq / (max_prescale + 1) / max_divider)
Setting a maximum timeout value will allow the watchdog core to refuse
user-space calls to the WDIOC_SETTIMEOUT ioctl that sets not supported
timeout values.
For example, systemd tries to set a timeout of 10 minutes on reboot to
ensure that the machine will be rebooted even if a reboot failed. This
leads to the following error message on an Exynos5422 Odroid XU4 board:
[ 147.986045] s3c2410-wdt 101d0000.watchdog: timeout 600 too big
Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
According to Server Base System Architecture (SBSA) specification,
the SBSA Generic Watchdog has two stage timeouts: the first signal (WS0)
is for alerting the system by interrupt, the second one (WS1) is a real
hardware reset.
More details about the hardware specification of this device:
ARM DEN0029B - Server Base System Architecture (SBSA)
This driver can operate ARM SBSA Generic Watchdog as a single stage watchdog
or a two stages watchdog, it's set up by the module parameter "action".
In the single stage mode, when the timeout is reached, your system
will be reset by WS1. The first signal (WS0) is ignored.
In the two stages mode, when the timeout is reached, the first signal (WS0)
will trigger panic. If the system is getting into trouble and cannot be reset
by panic or restart properly by the kdump kernel(if supported), then the
second stage (as long as the first stage) will be reached, system will be
reset by WS1. This function can help administrator to backup the system
context info by panic console output or kdump.
This driver bases on linux kernel watchdog framework, so it can get
timeout from module parameter and FDT at the driver init stage.
Signed-off-by: Fu Wei <fu.wei@linaro.org>
Reviewed-by: Graeme Gregory <graeme.gregory@linaro.org>
Tested-by: Pratyush Anand <panand@redhat.com>
Acked-by: Timur Tabi <timur@codeaurora.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Pull sparc fixes from David Miller:
1) System call tracing doesn't handle register contents properly across
the trace. From Mike Frysinger.
2) Hook up copy_file_range
3) Build fix for 32-bit with newer tools.
4) New sun4v watchdog driver, from Wim Coekaerts.
5) Set context system call has to allow for servicable faults when we
flush the register windows to memory
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
sparc64: Fix sparc64_set_context stack handling.
sparc32: Add -Wa,-Av8 to KBUILD_CFLAGS.
Add sun4v_wdt watchdog driver
sparc: Fix system call tracing register handling.
sparc: Hook up copy_file_range syscall.
The WinSystems EBC-C384 has an onboard watchdog timer. The timeout range
supported by the watchdog timer is 1 second to 255 minutes. Timeouts
under 256 seconds have a 1 second granularity, while the rest have a 1
minute granularity.
This driver adds watchdog timer support for this onboard watchdog timer.
The timeout may be configured via the timeout module parameter.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Add support for the watchdog timer on NI cRIO-903x and cDAQ-913x real-
time controllers.
Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
The 'action' (or restart mode) and data parameters may be used by restart
handlers, so they should be passed to the restart callback functions.
Cc: Sylvain Lemieux <slemieux@tycoint.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
The Zodiac watchdog is implemented on a microcontoller. The reset reason
currently labelled "trigger" is not to detect when the watchdog has
triggered (as had been initially understood and suggested by the naming),
but to inform the reader that the watchdog, which in fact has it's own
hardware watchdog, has been reset because the hardware watchdog has
triggered. Renaming to "hw watchdog".
Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Hidehiro Kawai
Linus Torvalds
Guenter Roeck
Sylvain Lemieux
Wolfram Sang
Javier Martinez Canillas
Fu Wei
Greg Kroah-Hartman
William Breathitt Gray
Kyle Roeschley
Martyn Welch