kernel/linux.git/drivers/watchdog/watchdog_dev.c, branch linux-4.7.y

watchdog: core: Clear WDOG_HW_RUNNING before calling the stop function

2016-10-07T13:21:24+00:00

commit 3c10bbde10fe4dca52726e246cefa6b0a1dfbd3e upstream. WDOG_HW_RUNNING indicates that the hardware watchdog is running while the watchdog device is closed. The flag may be set by the driver when it is instantiated to indicate that the watchdog is running, and that the watchdog core needs to send heartbeat requests to the driver until the watchdog device is opened. When the watchdog device is closed, the flag can be used by the driver's stop function to indicate to the watchdog core that it was unable to stop the watchdog, and that the watchdog core needs to send heartbeat requests. This only works if the flag is actually cleared when the watchdog is stopped. To avoid having to clear the flag in each driver's stop function, clear it in the watchdog core before calling the stop function. Reported-by: Rasmus Villemoes Fixes: ee142889e32f ("watchdog: Introduce WDOG_HW_RUNNING flag") Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman

watchdog: core: Fix circular locking dependency

2016-05-14T14:10:33+00:00

lockdep reports the following circular locking dependency. ====================================================== INFO: possible circular locking dependency detected ] 4.6.0-rc3-00191-gfabf418 #162 Not tainted ------------------------------------------------------- systemd/1 is trying to acquire lock: ((&(&wd_data->work)->work)){+.+...}, at: [<80141650>] flush_work+0x0/0x280 but task is already holding lock: (&wd_data->lock){+.+...}, at: [<804acfa8>] watchdog_release+0x18/0x190 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&wd_data->lock){+.+...}: [<80662310>] mutex_lock_nested+0x64/0x4a8 [<804aca4c>] watchdog_ping_work+0x18/0x4c [<80143128>] process_one_work+0x1ac/0x500 [<801434b4>] worker_thread+0x38/0x554 [<80149510>] kthread+0xf4/0x108 [<80107c10>] ret_from_fork+0x14/0x24 -> #0 ((&(&wd_data->work)->work)){+.+...}: [<8017c4e8>] lock_acquire+0x70/0x90 [<8014169c>] flush_work+0x4c/0x280 [<801440f8>] __cancel_work_timer+0x9c/0x1e0 [<804acfcc>] watchdog_release+0x3c/0x190 [<8022c5e8>] __fput+0x80/0x1c8 [<80147b28>] task_work_run+0x94/0xc8 [<8010b998>] do_work_pending+0x8c/0xb4 [<80107ba8>] slow_work_pending+0xc/0x20 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&wd_data->lock); lock((&(&wd_data->work)->work)); lock(&wd_data->lock); lock((&(&wd_data->work)->work)); *** DEADLOCK *** 1 lock held by systemd/1: stack backtrace: CPU: 2 PID: 1 Comm: systemd Not tainted 4.6.0-rc3-00191-gfabf418 #162 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [<8010f5e4>] (unwind_backtrace) from [<8010c038>] (show_stack+0x10/0x14) [<8010c038>] (show_stack) from [<8039d7fc>] (dump_stack+0xa8/0xd4) [<8039d7fc>] (dump_stack) from [<80177ee0>] (print_circular_bug+0x214/0x334) [<80177ee0>] (print_circular_bug) from [<80179230>] (check_prevs_add+0x4dc/0x8e8) [<80179230>] (check_prevs_add) from [<8017b3d8>] (__lock_acquire+0xc6c/0x14ec) [<8017b3d8>] (__lock_acquire) from [<8017c4e8>] (lock_acquire+0x70/0x90) [<8017c4e8>] (lock_acquire) from [<8014169c>] (flush_work+0x4c/0x280) [<8014169c>] (flush_work) from [<801440f8>] (__cancel_work_timer+0x9c/0x1e0) [<801440f8>] (__cancel_work_timer) from [<804acfcc>] (watchdog_release+0x3c/0x190) [<804acfcc>] (watchdog_release) from [<8022c5e8>] (__fput+0x80/0x1c8) [<8022c5e8>] (__fput) from [<80147b28>] (task_work_run+0x94/0xc8) [<80147b28>] (task_work_run) from [<8010b998>] (do_work_pending+0x8c/0xb4) [<8010b998>] (do_work_pending) from [<80107ba8>] (slow_work_pending+0xc/0x20) Turns out the call to cancel_delayed_work_sync() in watchdog_release() is not necessary and can be dropped. If the worker is no longer necessary, the subsequent call to watchdog_update_worker() will cancel it. If it is already running, it won't do anything, since the worker function checks if it needs to ping the watchdog or not. Reported-by: Clemens Gruber Tested-by: Clemens Gruber Fixes: 11d7aba9ceb7 ("watchdog: imx2: Convert to use infrastructure triggered keepalives") Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Cc: stable

watchdog: Ensure that wdd is not dereferenced if NULL

2016-03-16T20:11:50+00:00

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 Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck

watchdog: Add support for minimum time between heartbeats

2016-03-16T20:11:19+00:00

Some watchdogs require a minimum time between heartbeats. Examples are the watchdogs in DA9062 and AT91SAM9x. Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck

watchdog: Make stop function optional

2016-03-16T20:11:16+00:00

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 Signed-off-by: Wim Van Sebroeck

watchdog: Introduce WDOG_HW_RUNNING flag

2016-03-16T20:11:15+00:00

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 Signed-off-by: Wim Van Sebroeck

watchdog: Introduce hardware maximum heartbeat in watchdog core

2016-03-16T20:11:14+00:00

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 Signed-off-by: Wim Van Sebroeck

watchdog: Make set_timeout function optional

2016-03-16T20:11:07+00:00

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 Signed-off-by: Wim Van Sebroeck

watchdog: Drop pointer to watchdog device from struct watchdog_device

2016-01-11T20:53:59+00:00

The lifetime of the watchdog device pointer is different from the lifetime of its character device. Remove it entirely to avoid race conditions. Signed-off-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck

watchdog: Add support for creating driver specific sysfs attributes

2016-01-11T20:53:57+00:00

The Zodiac watchdog driver attaches additional sysfs attributes to the watchdog device. This has a number of problems: The watchdog device lifetime differs from the driver lifetime, and the device structure should therefore not be accessed from drivers. Also, creating sysfs attributes after driver registration results in a potential race condition if user space expects the attributes to exist but they don't exist yet. Add support for creating driver specific sysfs attributes to the watchdog core to solve the problems. Signed-off-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck