linux-kernel - Re: Lowering the log level in watchdog_dev

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 12 Oct 2017 19:15:59 +0100
From:   Radu Rendec <rrendec@...sta.com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Wim Van Sebroeck <wim@...ana.be>, linux-watchdog@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: Lowering the log level in watchdog_dev_register when err==-EBUSY

On Wed, 2017-10-11 at 11:46 -0700, Guenter Roeck wrote:
> On Wed, Oct 11, 2017 at 06:46:31PM +0100, Radu Rendec wrote:
> > In a project I'm working on we have a valid use case where we activate
> > both the i6300esb and softdog watchdogs. We always activate i6300esb
> > first (which uses the "legacy" watchdog API) and then softdog. This
> > gets us two "error" level messages (coming from watchdog_cdev_register)
> > although softdog falls back to the "new" API and registers its char
> > device just fine.
> > 
> > Since watchdog_cdev_register/watchdog_dev_register seem to be used only
> > by watchdog_register_device and the latter always falls back to the
> > "new" API, I'm thinking about lowering the log level of these messages
> > when err is -EBUSY.
>
> I would suggest to convert the offending driver to use the watchdog subsystem
> (and along the line remove the restriction of only supporting a single
> instance). You have the hardware, so that should be a straightforward change.

Thanks for the suggestion! That makes sense. I will start working on
converting i6300esb and submit a patch in a few days.

By the way, I don't have the hardware. I'm using it with KVM (Qemu),
but I guess that's good enough since I'm not going to touch any of the
code parts that deal with the hardware.

Radu