From: Guenter Roeck <linux@roeck-us.net>
To: linux-watchdog@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Guenter Roeck <linux@roeck-us.net>
Subject: [PATCH 0/8] watchdog: core: Fix locking, lifetime, suspend, and state management bugs
Date: Tue, 29 Sep 2026 06:46:27 -0700 [thread overview]
Message-ID: <20260929134635.2567137-1-linux@roeck-us.net> (raw)
This series fixes several locking, reference counting, object lifetime,
suspend/resume, and state management bugs in the watchdog core character
device and timer handling:
1. watchdog: core: Clear wd_data pointer on errors
Clear wdd->wd_data on all registration error paths in
watchdog_cdev_register(), and clear wd_data->wdd under wd_data->lock
when failing after misc_register() may have exposed the device to
userspace, preventing dangling pointers.
2. watchdog: core: Add missing locks
Acquire wd_data->lock in watchdog_open(), across watchdog_stop() and
pretimeout teardown in watchdog_cdev_unregister(), and in
watchdog_set_last_hw_keepalive(). Also protect old_wd_data with
old_wd_data_lock to prevent races when opening or unregistering
/dev/watchdog.
3. watchdog: core: Prevent ping worker from re-arming timer on suspend
Introduce a _WDOG_SUSPENDED flag in wd_data->status, set under
wd_data->lock during suspend and cleared on resume, and check it in
watchdog_worker_should_ping(), watchdog_need_worker(), and
__watchdog_ping() so an in-flight worker or deferred ping cannot
re-arm wd_data->timer while suspended.
4. watchdog: core: Stop pretimeout hrtimer on suspend
Stop the software pretimeout hrtimer in watchdog_dev_suspend(),
prevent watchdog_hrtimer_pretimeout_start() from arming it while
_WDOG_SUSPENDED is set, and restart it in watchdog_dev_resume() if
the hardware watchdog is running.
5. watchdog: core: Restore WDOG_HW_RUNNING if stopping watchdog fails
In watchdog_stop(), WDOG_HW_RUNNING is cleared before calling
wdd->ops->stop(). Restore WDOG_HW_RUNNING if wdd->ops->stop() returns
an error so the core continues to track the running hardware state
and retains its module and device references.
6. watchdog: core: Cancel timer if cdev_device_add() fails
Initialize wd_data and acquire running-watchdog module and device
references prior to calling misc_register(). On registration failure
(and in watchdog_cdev_unregister()), stop the watchdog if appropriate,
stop the pretimeout hrtimer, release unclaimed running-watchdog
references if the device is not open, and cancel wd_data->timer and
wd_data->work before dropping the initial device reference.
7. watchdog: core: Fix unbalanced module_put() in watchdog_open()
In watchdog_open(), try_module_get() is skipped when hw_running is
true because the module reference was already taken when the running
watchdog was registered. Guard module_put() on the watchdog_start()
error path with !hw_running to avoid dropping a reference that
watchdog_open() did not acquire.
8. watchdog: core: Update last_keepalive in watchdog_start()
When starting a watchdog whose hardware is already running, set
WDOG_ACTIVE and update wd_data->last_keepalive to started_at before
calling __watchdog_ping() so that watchdog_get_timeleft() reports the
correct remaining time and watchdog_update_worker() inside
__watchdog_ping() evaluates the active state and new keepalive
timestamp rather than a potentially expired open_deadline. If
__watchdog_ping() fails, clear WDOG_ACTIVE and update the worker.
Disclaimer: I started this series to fix a number of bugs reported
by Sashiko in the watchdog core. After several fix-review rounds, I did
not get closer to fixing all issues reported by Sashiko; either my patches
turned out to be incomplete or buggy. I finally gave up and fed Sashiko's
review feedback into an AI engine, asking it to fix the reported problems.
It still took some 10+ rounds of review/fix, but the resulting patches
should fix at least the most critical race conditions in the watchdog core.
Given the complexity of the changes, the plan is to apply the series
during the next commit window, to be released with v7.4, and to
eventually back-port it to older kernel branches.
----------------------------------------------------------------
Guenter Roeck (8):
watchdog: core: Clear wd_data pointer on errors
watchdog: core: Add missing locks
watchdog: core: Prevent ping worker from re-arming timer on suspend
watchdog: core: Stop pretimeout hrtimer on suspend
watchdog: core: Restore WDOG_HW_RUNNING if stopping watchdog fails
watchdog: core: Cancel timer if cdev_device_add() fails
watchdog: core: Fix unbalanced module_put() in watchdog_open()
watchdog: core: Update last_keepalive in watchdog_start()
drivers/watchdog/watchdog_core.h | 1 +
drivers/watchdog/watchdog_dev.c | 155 ++++++++++++++++++-------
drivers/watchdog/watchdog_hrtimer_pretimeout.c | 3 +-
3 files changed, 117 insertions(+), 42 deletions(-)
next reply other threads:[~2026-09-29 13:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 13:46 Guenter Roeck [this message]
2026-09-29 13:46 ` [PATCH 1/8] watchdog: core: Clear wd_data pointer on errors Guenter Roeck
2026-09-29 13:46 ` [PATCH 2/8] watchdog: core: Add missing locks Guenter Roeck
2026-09-29 13:46 ` [PATCH 3/8] watchdog: core: Prevent ping worker from re-arming timer on suspend Guenter Roeck
2026-09-29 13:46 ` [PATCH 4/8] watchdog: core: Stop pretimeout hrtimer " Guenter Roeck
2026-09-29 13:46 ` [PATCH 5/8] watchdog: core: Restore WDOG_HW_RUNNING if stopping watchdog fails Guenter Roeck
2026-09-29 13:46 ` [PATCH 6/8] watchdog: core: Cancel timer if cdev_device_add() fails Guenter Roeck
2026-09-29 13:46 ` [PATCH 7/8] watchdog: core: Fix unbalanced module_put() in watchdog_open() Guenter Roeck
2026-09-29 13:46 ` [PATCH 8/8] watchdog: core: Update last_keepalive in watchdog_start() Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260929134635.2567137-1-linux@roeck-us.net \
--to=linux@roeck-us.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®