mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Cc: Wim Van Sebroeck <wim@iguana.be>,
	Jonathan Corbet <corbet@lwn.net>,
	Sebastian Reichel <sebastian.reichel@collabora.co.uk>,
	esben.haabendal@gmail.com, Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
	linux-watchdog@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [v6, 2/3] watchdog: introduce watchdog.open_timeout commandline parameter
Date: Sat, 8 Jul 2017 08:12:47 -0700	[thread overview]
Message-ID: <20170708151247.GA15051@roeck-us.net> (raw)
In-Reply-To: <1496134608-7375-3-git-send-email-rasmus.villemoes@prevas.dk>

On Tue, May 30, 2017 at 10:56:46AM +0200, Rasmus Villemoes wrote:
> The watchdog framework takes care of feeding a hardware watchdog until
> userspace opens /dev/watchdogN. If that never happens for some reason
> (buggy init script, corrupt root filesystem or whatnot) but the kernel
> itself is fine, the machine stays up indefinitely. This patch allows
> setting an upper limit for how long the kernel will take care of the
> watchdog, thus ensuring that the watchdog will eventually reset the
> machine.
> 
> This is particularly useful for embedded devices where some fallback
> logic is implemented in the bootloader (e.g., use a different root
> partition, boot from network, ...).
> 
> The open timeout is also used as a maximum time for an application to
> re-open /dev/watchdogN after closing it.
> 
> A value of 0 (the default) means infinite timeout, preserving the
> current behaviour.
> 
> The unit is milliseconds rather than seconds because that covers more
> use cases. For example, one can effectively disable the kernel handling
> by setting the open_timeout to 1 ms. There are also customers with very
> strict requirements that may want to set the open_timeout to something
> like 4500 ms, which combined with a hardware watchdog that must be
> pinged every 250 ms ensures userspace is up no more than 5 seconds after
> the bootloader hands control to the kernel (250 ms until the driver gets
> registered and kernel handling starts, 4500 ms of kernel handling, and
> then up to 250 ms from the last ping until userspace takes over).
> 
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

I finally found the time to look into this. It is sufficiently different
to handle_boot_enabled to keep it separate. I am mostly ok with the patch.
One comment below.

> ---
>  Documentation/watchdog/watchdog-parameters.txt |  8 ++++++++
>  drivers/watchdog/watchdog_dev.c                | 26 +++++++++++++++++++++++++-
>  2 files changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt
> index 914518a..8577c27 100644
> --- a/Documentation/watchdog/watchdog-parameters.txt
> +++ b/Documentation/watchdog/watchdog-parameters.txt
> @@ -8,6 +8,14 @@ See Documentation/admin-guide/kernel-parameters.rst for information on
>  providing kernel parameters for builtin drivers versus loadable
>  modules.
>  
> +The watchdog core parameter watchdog.open_timeout is the maximum time,
> +in milliseconds, for which the watchdog framework will take care of
> +pinging a hardware watchdog until userspace opens the corresponding
> +/dev/watchdogN device. A value of 0 (the default) means an infinite
> +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.
> +
>  
>  -------------------------------------------------
>  acquirewdt:
> diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
> index caa4b90..c807067 100644
> --- a/drivers/watchdog/watchdog_dev.c
> +++ b/drivers/watchdog/watchdog_dev.c
> @@ -66,6 +66,7 @@ struct watchdog_core_data {
>  	struct mutex lock;
>  	unsigned long last_keepalive;
>  	unsigned long last_hw_keepalive;
> +	unsigned long open_deadline;
>  	struct delayed_work work;
>  	unsigned long status;		/* Internal status bits */
>  #define _WDOG_DEV_OPEN		0	/* Opened ? */
> @@ -80,6 +81,21 @@ static struct watchdog_core_data *old_wd_data;
>  
>  static struct workqueue_struct *watchdog_wq;
>  
> +static unsigned open_timeout;
> +module_param(open_timeout, uint, 0644);

MODULE_PARM_DESC is missing. I would also prefer to keep module_param()
and MODULE_PARM_DESC() together with the existing module parameter, ie at
the end of the file.

Thanks,
Guenter

  reply	other threads:[~2017-07-08 15:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-22 14:06 [PATCH v5 0/3] watchdog: allow setting deadline for opening /dev/watchdogN Rasmus Villemoes
2017-05-22 14:06 ` [PATCH v5 1/3] watchdog: introduce watchdog_worker_should_ping helper Rasmus Villemoes
2017-05-25  0:53   ` Guenter Roeck
2017-05-22 14:06 ` [PATCH v5 2/3] watchdog: introduce watchdog.open_timeout commandline parameter Rasmus Villemoes
2017-05-25  0:56   ` Guenter Roeck
2017-05-30  8:00     ` Rasmus Villemoes
2017-05-22 14:06 ` [PATCH v5 3/3] watchdog: introduce CONFIG_WATCHDOG_OPEN_TIMEOUT Rasmus Villemoes
2017-05-22 18:07 ` [PATCH v5 0/3] watchdog: allow setting deadline for opening /dev/watchdogN Alan Cox
2017-05-22 19:44   ` Guenter Roeck
2017-05-23  7:15   ` Rasmus Villemoes
2017-05-24 14:19 ` Esben Haabendal
2017-05-30  8:56 ` [PATCH v6 " Rasmus Villemoes
2017-05-30  8:56   ` [PATCH v6 1/3] watchdog: introduce watchdog_worker_should_ping helper Rasmus Villemoes
2017-05-30  8:56   ` [PATCH v6 2/3] watchdog: introduce watchdog.open_timeout commandline parameter Rasmus Villemoes
2017-07-08 15:12     ` Guenter Roeck [this message]
2017-05-30  8:56   ` [PATCH v6 3/3] watchdog: introduce CONFIG_WATCHDOG_OPEN_TIMEOUT Rasmus Villemoes
2017-07-08 15:15     ` [v6,3/3] " Guenter Roeck
2017-07-11 15:50       ` Wim Van Sebroeck
2017-06-06  8:08   ` [PATCH v6 0/3] watchdog: allow setting deadline for opening /dev/watchdogN Rasmus Villemoes
2017-06-06 13:47     ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170708151247.GA15051@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=corbet@lwn.net \
    --cc=esben.haabendal@gmail.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=rasmus.villemoes@prevas.dk \
    --cc=sebastian.reichel@collabora.co.uk \
    --cc=wim@iguana.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome