From: "liuchao (CR)" <liuchao173@huawei.com>
To: "linux@roeck-us.net" <linux@roeck-us.net>
Cc: caihe <caihe@huawei.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
lixiaokeng <lixiaokeng@huawei.com>,
"wim@linux-watchdog.org" <wim@linux-watchdog.org>
Subject: Re: [PATCH] watchdog: only print critical log when the watchdog fails to be stopped
Date: Wed, 5 Feb 2025 02:02:50 +0000 [thread overview]
Message-ID: <13073a1dfb7946af98565921c609bd6f@huawei.com> (raw)
On 1/27/2025 22:30, Guenter Roeck wrote:
> On 1/27/25 01:35, liuchao (CR) wrote:
> > On 1/26/25 21:10, Guenter Roeck wrote:
> >> On 1/26/25 00:38, Liu Chao wrote:
> >>> Every time the user echoes 0 > /dev/watchdog0, meaningless critical
> >>> log is printed.
> >>>
> >>
> >> It is not meaningless, and it will still be displayed after this
> >> change, making the change pointless.
> >
> > The change is not pointless. For example, the softdog driver does not
> > invoke watchdog_stop or print logs in the watchdog_release.
> >
>
> It seems to me that is a problem in the softdog driver.
>
> The change is actually worse than I initially thought.
> The message is _supposed_ to be displayed if watchdog_stop() is not called while
> the watchdog is running (i.e., if err == -EBUSY).
> Otherwise it would not be displayed for real hardware watchdogs which are not
> stopped because they were running and watchdog_stop() is not called because
> WDIOF_MAGICCLOSE is set in the driver and the magic release byte was not
> written.
>
> Specifically, the softdog driver has WDIOF_MAGICCLOSE set. It is not supposed
> to be unloadable (or unloaded) while the watchdog is running.
When echo to /dev/watchdog0, The watchdog_open, watchdog_write, and
watchdog_release functions are invoked in sequence. Do you mean the softdog
driver should not call watchdog_release?
After the user opens /dev/watchdog0, the user feeds the watchdog through ioctl
WDIOC_KEEPALIVE and never closes. Is this the correct usage?
>
> Guenter
next reply other threads:[~2025-02-05 2:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-05 2:02 liuchao (CR) [this message]
2025-02-05 2:35 ` Guenter Roeck
-- strict thread matches above, loose matches on Subject: below --
2025-02-05 3:14 liuchao (CR)
2025-02-05 4:28 ` Guenter Roeck
2025-02-05 5:20 ` Guenter Roeck
2025-01-27 9:44 liuchao (CR)
2025-01-27 9:35 liuchao (CR)
2025-01-27 14:29 ` Guenter Roeck
2025-01-26 8:38 Liu Chao
2025-01-26 13:10 ` 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=13073a1dfb7946af98565921c609bd6f@huawei.com \
--to=liuchao173@huawei.com \
--cc=caihe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lixiaokeng@huawei.com \
--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 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®