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]
Message-ID: <20190501000511.GA25050@anatevka>
Date:   Tue, 30 Apr 2019 18:05:11 -0600
From:   Jerry Hoemann <jerry.hoemann@....com>
To:     Rasmus Villemoes <rasmus.villemoes@...vas.dk>
Cc:     "linux-watchdog@...r.kernel.org" <linux-watchdog@...r.kernel.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Wim Van Sebroeck <wim@...ux-watchdog.org>,
        Jonathan Corbet <corbet@....net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        Esben Haabendal <esben@...bendal.dk>,
        "martin@...deboll.net" <martin@...deboll.net>,
        Rasmus Villemoes <Rasmus.Villemoes@...vas.se>
Subject: Re: [PATCH v9 0/3] watchdog: allow setting deadline for opening
 /dev/watchdogN

On Mon, Jan 21, 2019 at 08:45:38PM +0000, Rasmus Villemoes wrote:
> If a watchdog driver tells the framework that the device is running,
> the framework takes care of feeding the watchdog until userspace opens
> the device. If the userspace application which is supposed to do that
> never comes up properly, the watchdog is fed indefinitely by the
> kernel. This can be especially problematic for embedded devices.
> 
> The existing handle_boot_enabled cmdline parameter/config option
> partially solves that, but that is only usable for the subset of
> hardware watchdogs that have (or can be configured by the bootloader
> to have) a timeout that is sufficient to make it realistic for
> userspace to come up. Many devices have timeouts of only a few
> seconds, or even less, making handle_boot_enabled insufficient.
> 
> These patches allow one to set a maximum time for which the kernel
> will feed the watchdog, thus ensuring that either userspace has come
> up, or the board gets reset. This allows fallback logic in the
> bootloader to attempt some recovery (for example, if an automatic
> update is in progress, it could roll back to the previous version).
> 

Rasmus,

Sorry if I missed it, but are you still looking into adding
this feature?  I was thinking it might also be useful with
kdump when a watchdog was running in the first kernel.

After a panic if kdump is configured, the system will boot the
crash kernel.  If a watchdog was running in the first kernel
it would still running in the crash kernel environment.

Some of the drivers on HPE systems take a non-trivial amount of time
to reset during the crash kernel boot, so it would be good to have
the core pet the watchdog until user space is ready.  But as the
crash kernel environment has its issues,  we really don't want
the core to ping the watchdog indefinitely.

Thanks

Jerry

-- 

-----------------------------------------------------------------------------
Jerry Hoemann                  Software Engineer   Hewlett Packard Enterprise
-----------------------------------------------------------------------------

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ