linux-kernel - Re: [PATCH] watchdog: only print critical log when the watchdog fails to be stopped

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e9b135a6-f398-4acb-b3ab-01732e94645c@roeck-us.net>
Date: Tue, 4 Feb 2025 20:28:44 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: "liuchao (CR)" <liuchao173@...wei.com>
Cc: caihe <caihe@...wei.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-watchdog@...r.kernel.org" <linux-watchdog@...r.kernel.org>,
 lixiaokeng <lixiaokeng@...wei.com>,
 "wim@...ux-watchdog.org" <wim@...ux-watchdog.org>
Subject: Re: [PATCH] watchdog: only print critical log when the watchdog fails
 to be stopped

On 2/4/25 19:14, liuchao (CR) wrote:
> On 2/3/2025 18:35, Guenter Roeck wrote:
>> On 2/4/25 18:02, liuchao (CR) wrote:
>>> 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?
>>>
>>
>> I tried softdog. It works as advertised. Yes, "echo 0 > watchdog0" triggers the
>> message.
>> "sudo modprobe -r softdog" then fails with
>>
>> 	modprobe: FATAL: Module softdog is in use.
>>
>> and, as expected, one minute later (or whatever the timeout is set to) the
>> system reboots.
>>
>> There is nothing wrong with the message. The softdog _does_ refuse to be
>> unloaded while running, and it _does_ reboot the system after the timeout
>> expired. This is all perfectly as expected. The log is not meaningless. Instead, it
>> tells the user that the system will reboot after the watchdog expired. Which it
>> does.
> 
> User creates a process and echoes every time to ensure that the system is
> normal, the process can be executed properly. Otherwise, the system reboots.
> So the critical message keeps printing.
> 
> Is it reasonable to change it to info level?
> 

No. The user needs to echo the magic character instead of "0".

Guenter