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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 9 May 2022 18:15:39 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Mario Limonciello <mario.limonciello@....com>,
        Jerry.Hoemann@....com
Cc:     Wim Van Sebroeck <wim@...ux-watchdog.org>,
        "open list:WATCHDOG DEVICE DRIVERS" <linux-watchdog@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>, ionut_n2001@...oo.com
Subject: Re: [PATCH] Watchdog: sp5100_tco: Lower verbosity of disabled
 watchdog hardware

On 5/9/22 17:37, Mario Limonciello wrote:
> On 5/9/22 19:33, Jerry Hoemann wrote:
>> On Mon, May 09, 2022 at 03:55:54PM -0700, Guenter Roeck wrote:
>>> On 5/9/22 09:33, Mario Limonciello wrote:
>>>> If watchdog hardware has been disabled, currently the kernel driver
>>>> will show at err level during probe:
>>>>
>>>> "Watchdog hardware is disabled"
>>>>
>>>> This is unnecessarily verbose as there is already a -ENODEV returned.
>>>> Lower the level to debug.
>>>
>>> Is it ? Without this message, a user may try to load the driver,
>>> get an error message, and have no idea why the driver was not
>>> enabled even though the hardware exists. If anything , -ENODEV
>>> is less than perfect. Unfortunately there does not seem to be
>>> a better error code, or at least I don't see one.
>>>
>>> Guenter
>>
>> Coincidentally, I was looking at this code on Friday.
>>
>> Some HPE Proliant servers are disabling the AMD WDT in BIOS.  However,
>> sp5100_tco was still getting configured.  It was the lack of
>> "Watchdog hardware is disabled" message that helped clue us into
>> what was going on (Linux is enabling the WDT anyway.)
>>
>> So, I liked that this message exists.
>>
>> I'll send an RFC patch for this other issue as it orthogonal.
>> But just wanted to point out the message is useful.
> 
> I personally don't have a problem blacklisting on a system I encounter this. I take anything at "err" level as there is a firmware problem or a hardware problem that should be looked at.
> 
> As the message is genuinely useful as Jerry points out how about meeting in the middle at info or notice?
> 

I really don't want to change it. It does point out a serious issue,
intentional or not. Anyone concerned or disturbed about the message
can easily block the module from loading, and others may rely on it.
 From driver perspective it _is_ an error, and it should be treated
as such.

Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ