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: <d209130522dc4752bb4ec56c783aac4a@asem.it>
Date:   Tue, 13 Apr 2021 09:09:32 +0000
From:   Flavio Suligoi <f.suligoi@...m.it>
To:     Guenter Roeck <linux@...ck-us.net>
CC:     Mika Westerberg <mika.westerberg@...ux.intel.com>,
        "linux-watchdog@...r.kernel.org" <linux-watchdog@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Wim Van Sebroeck" <wim@...ux-watchdog.org>
Subject: RE: [PATCH v1] watchdog: add new parameter to start the watchdog on
 module insertion

Hi Guenter,

...

> >>> The new parameter "start_enabled" starts the watchdog at the same time
> >>> of the module insertion.
> >>> This feature is very useful in embedded systems, to avoid cases where
> >>> the system hangs before reaching userspace.
> >>>
> >>> This function can be also enabled in the kernel config, so can be
> >>> used when the watchdog driver is build as built-in.
> >>>
> >>> This parameter involves the "core" section of the watchdog driver;
> >>> in this way it is common for all the watchdog hardware implementations.
> >>>
> >>> Note: to use only for watchdog drivers which doesn't support this
> >>>       parameter by itself.
> >>>
> >>> Signed-off-by: Flavio Suligoi <f.suligoi@...m.it>
> >>> ---
> >>>  Documentation/watchdog/watchdog-parameters.rst |  5 +++++
> >>>  drivers/watchdog/Kconfig                       | 14 ++++++++++++++
> >>>  drivers/watchdog/watchdog_core.c               | 12 ++++++++++++
> >>>  3 files changed, 31 insertions(+)
> >>>
> >>> diff --git a/Documentation/watchdog/watchdog-parameters.rst
> >> b/Documentation/watchdog/watchdog-parameters.rst
> >>> index 223c99361a30..623fd064df91 100644
> >>> --- a/Documentation/watchdog/watchdog-parameters.rst
> >>> +++ b/Documentation/watchdog/watchdog-parameters.rst
> >>> @@ -21,6 +21,11 @@ watchdog core:
> >>>  	timeout. Setting this to a non-zero value can be useful to ensure that
> >>>  	either userspace comes up properly, or the board gets reset and allows
> >>>  	fallback logic in the bootloader to try something else.
> >>> +    start_enabled:
> >>> +	Watchdog is started on module insertion. This option can be also
> >>> +	selected by kernel config (default=kernel config parameter).
> >>> +	Use only for watchdog drivers which doesn't support this parameter
> >>> +	by itself.
> >>
> >> Why ?
> >
> > There are two drivers with an analogous feature (pnx833x_wdt and
> > omap_wdt) and it is important not to enable the watchdog twice.
> >
> Why ?

right, it is a nonsense ...

> 
> > Ok, I can substitute the sentence: " Use only for watchdog drivers
> > which doesn't support this parameter itself." with another one, like:
> > "If the driver supports this feature by itself, be carefully not to enable
> > the watchdog twice".
> >
> > What do you think?
> >
> 
> I am still missing the explanation _why_ it would be important not to enable
> a watchdog twice. Why does it matter ? What is the difference ?
> 
> If there is a concern that the start function should not be called on an already
> running watchdog, the code could check for that and ensure that
> WDOG_HW_RUNNING
> is not already set before enabling it. That would probably make sense anyway.
> But adding a limitation/restriction like the above, which is not enforceable,
> is not a good idea. How would the common user know if a watchdog is already
> running (eg because it was started in BIOS/ROMMON) ?

Yes, right! I have to check WDOG_HW_RUNNING before starting the watchdog.
It is the correct way to manage this feature, in any case and for any wdog driver.

> 
> Thanks,
> Guenter

Thank you very much Guenter!
Regards,
Flavio

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ