From: chaithco@redhat.com
To: Guenter Roeck <linux@roeck-us.net>
Cc: wim@linux-watchdog.org, linux-watchdog@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Differentiate scenarios when watchdog is closed
Date: Thu, 27 Aug 2026 11:09:25 -0600 [thread overview]
Message-ID: <QBUFKT.6XP2A9BR6LRO3@redhat.com> (raw)
In-Reply-To: <2bd566ca-2696-46d3-aeec-57db66fa1902@roeck-us.net>
On Thu, Aug 27 2026 at 09:01:47 AM -07:00:00, Guenter Roeck
<linux@roeck-us.net> wrote:
> Presently
> [...]
> Also, the subject should start with the subsystem name ("watchdog:")
> [...]
> deliberately
Thank you for catching these! Please accept my apologies. I can fix
those up in the next submission.
> [...] Also, while technically userspace may close the
> watchdog deliberately while it is running, that is not what happens
> on a regular basis.
This is actually what initiated a bug report at
https://bugzilla.redhat.com/show_bug.cgi?id=1991285 it turns out
systemd explicitly does this to help ensure a system shutting down
actually eventually goes down even if the shutdown process hits some
snags. It does this on every shutdown. Given the prevalence of systemd,
this is a regular occurrence. The end result is that, when using iTCO,
it shows an error on every shutdown when systemd is in use as init.
> If you want to make a change, I would suggest to add an error message
> into watchdog_stop() to report an error if the stop callback returns
> an error. That would distinguish 2/3 without making functional
> changes.
Thank you! So something like this?
if (wdd->ops->stop) {
clear_bit(WDOG_HW_RUNNING, &wdd->status);
err = wdd->ops->stop(wdd);
+ if (err < 0)
+ pr_info("watchdog%d: closed while still
enabled!\n");
trace_watchdog_stop(wdd, err);
} else {
set_bit(WDOG_HW_RUNNING, &wdd->status);
While responding to this, an additional thought occurred to me; given
the primary reason a user would see this is because systemd is shutting
down a system, it may be more worth while to have systemd log something
about closing the watchdog without disarming it to at least explain a
pr_crit kernel log line. Otherwise, it just looks like "something bad
happened" with watchdog. I am additionally unsure of what would be best
to go in watchdog_stop that helps differentiate intentional closing of
the watchdog without disabling vs malicious/accidental closing. The
intent would lie within the entity closing the watchdog; "closed while
still enabled!" still seems like "something bad happened" with info on
if it was intentional or not.
Thank you!
- Charles
next prev parent reply other threads:[~2026-08-27 17:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 20:50 [PATCH] Differentiate scenarios when watchdog is closed Charles Haithcock
2026-08-24 21:07 ` sashiko-bot
2026-08-27 16:01 ` Guenter Roeck
2026-08-27 17:09 ` chaithco [this message]
2026-08-27 18:10 ` Guenter Roeck
2026-08-31 20:05 ` chaithco
2026-09-01 16:06 ` Guenter Roeck
2026-09-01 21:44 ` chaithco
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=QBUFKT.6XP2A9BR6LRO3@redhat.com \
--to=chaithco@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=wim@linux-watchdog.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.