linux-kernel - Re: [PATCH 2/2] watchdog: gpio_wdt: add "start-at-boot" feature

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]

Message-ID: <38253332-08da-54a6-5497-7b06b39756fb@vimar.com>
Date:   Fri, 23 Apr 2021 16:24:33 +0200
From:   Francesco Zanella <francesco.zanella@...ar.com>
To:     Rasmus Villemoes <rasmus.villemoes@...vas.dk>,
        linux-watchdog@...r.kernel.org, wim@...ux-watchdog.org,
        linux@...ck-us.net
Cc:     devicetree@...r.kernel.org, robh+dt@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] watchdog: gpio_wdt: add "start-at-boot" feature



On 23/04/21 13:36, Rasmus Villemoes wrote:
> On 21/04/2021 18.26, Francesco Zanella wrote:
>> If "start-at-boot" property is present in the device tree, start pinging
>> hw watchdog at probe, in order to take advantage of kernel configs:
> 
> (1) Are you aware of the recent proposal to add a similar feature on
> watchdog core level:
> 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2F%3Fq%3Dstart_enable&amp;data=04%7C01%7Cfrancesco.zanella%40vimar.com%7Cde549dd02adb45669ff208d9064c0739%7Ca1f008bcd59b4c668f8760fd9af15c7f%7C1%7C0%7C637547745887915290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=pcqWkd%2B4m6RSS4KwmjgIbLpaa0XSCAOQorwI%2BIle5uY%3D&amp;reserved=0
> 

Oh good! Happy to know that, I missed it, sorry, it's quite new.
That kind of work would have been my next proposal if this had been accepted.
Hope that it will be mainlined.

> (2) If you set always-running but not nowayout you essentially have what
> you want now: If userspace opens the device [within the limit set by
> OPEN_TIMEOUT if that is in effect], but then does a graceful close (i.e.
> writes 'V' immediately before close()), the kernel will assume
> responsibility for pinging the device. So the device isn't stopped as
> such, but if you can't trust the kernel thread/timer to keep it alive,
> the system is already mostly unusable. [Also, how reliable is that 'the
> timer is stopped if the gpio is set to be an input' anyway].
> 
> Rasmus
> 

No I would like to be able to totally disable it with stop, not that the kernel
will keep it pinged.

However, glad to know the news, I will follow the evolution.

Thanks, regards,

Francesco Zanella