Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2395984imu; Thu, 17 Jan 2019 13:27:16 -0800 (PST) X-Google-Smtp-Source: ALg8bN5iwukCxj52+/RVqbDTXsOCVpYl8cDE+q7sO8VAvSt2kQetY7c5zALvi4AOYG9wcbCTZSeD X-Received: by 2002:a63:9749:: with SMTP id d9mr14752618pgo.415.1547760436544; Thu, 17 Jan 2019 13:27:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547760436; cv=none; d=google.com; s=arc-20160816; b=uLdg5EtJnQgIYgeIyVozFDbxCl+M5DNBXBIdYpBSlwya/7W1aZBbz3r+f/GlshXQBz YTzRvglNp+325WXisykMKmi3ZL2WjTvOhZaBc+QohaHoGTymKUgvgJGP+Miih24DO7E/ SsBTm1sRldA00yqhSHmaUrD9lNKBXa4eQ9ZVQf6Wvnt+qHGu8XGScqgGEYIQlLO6sqhy qiPgwSO6xXF2gxQT6OuXcWYVhtnGxev/2/pIB0kFSHFJyXxN7NhSKAnsjF6an9mgriZ6 qNobH6VAMyzZq8uaOafLW+jsFnowz/w7gVhsXiz+jX94zmHHgPv14y3bMMuWb3I9HPxY wfiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=NWGobzW0BYoOoe4sPTgj6HUlUWE+wmwldwmLOgXsgc0=; b=CLfFJaeopEItc4GiSFpV8yJy3LCM3DXds60m+fiw2vqnltnXGhkEm+9ieFOLw1NG06 93NERqQy1Q8p5YVbYqvo1sZfhJfxZXyRPRX90dCPulRf8NuEUVw1IZE3QVwToxHhCkaG N1ut504Orp8E6Kp2p5i+QYKCieg2J3EzSJHE6f7CbJagkAxEuTjVjqDTwDmG+IrH/kPt 6hBgkzKPR0p8Qei++sHfuiz/BnpXLCkUrPcc9q9grieTbG8qzFMKbKrIoS7Mef2rgFMX H30sN5APBASO1YuwVS7R3874f7MiCvqMUBKWQI7K8GN5CuR7iN1qPU6LCKq7biQUf046 0kmQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=FF1ItXkF; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 9si2447707pgm.112.2019.01.17.13.26.57; Thu, 17 Jan 2019 13:27:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=FF1ItXkF; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729293AbfAQVY2 (ORCPT + 99 others); Thu, 17 Jan 2019 16:24:28 -0500 Received: from mail-pf1-f196.google.com ([209.85.210.196]:35086 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726905AbfAQVY1 (ORCPT ); Thu, 17 Jan 2019 16:24:27 -0500 Received: by mail-pf1-f196.google.com with SMTP id z9so5451934pfi.2; Thu, 17 Jan 2019 13:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=NWGobzW0BYoOoe4sPTgj6HUlUWE+wmwldwmLOgXsgc0=; b=FF1ItXkFJeN9zJSqe3b0wpCdljB//VtxEpNWDdqXWZARIBgeeh0E/VgREqWe7bWl0h K6LYRaY2OpjCcKHuhAQjsV8Ha4sFwpl09SK3o+WbQVGqCD+8NcwZhzNmcwh0PZB6lOks Ijf5PXE0ebqkTenmvSrRV460B7fAKBw2MAF9YCTl6zOAmZfodUgas5ylXHnaflKUSl8r mtciYrj/B2+osABSo1+PC13cE0wm3bXUBvjFbhmtNiIoeznrMD5czz1NUZpG9YKH9KjT nkXatCNSFFDi2rTBO08NIpwSVlpX8rRfSqf5inc6a5WCg/bMAZHtV8mUhZJJTFDHz7Pt DLHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=NWGobzW0BYoOoe4sPTgj6HUlUWE+wmwldwmLOgXsgc0=; b=Q8j+j85+yi6uIYlBKpwpH7BLxuBaqZ0QY0pV7Xldw7erZBR7M52Nb4ZwfNYf6qtZwy A7H+RUmGHMy07oXVEZds6VP27ypFycgvRNWeZGBhWHIFZ+eWvtTuHVK7m4iJ+291JPgo b7SkkaYUq5jLBEfECEA9rG1BxO76B+MapeM709gm0dcxcbrAHaESQE91/YibYrcepDz4 K8SwC6mynSve7dLmZJS3r23uo/V1OAN9bM4nWJTR+9w/I3unsVg9bLjslpjSNCj039iW nQ/Ft1XUMQKZ40mRi90WSoHz1w7VLIF5tXP6unTXBhrDPUGj/OZifKAEC4/MO6MTya0P pvbw== X-Gm-Message-State: AJcUukcEqX63jpVI7fC0AVutTZK+TlKE2vetmjwPPFpPuOyV0fqsoBSk bJlzMAfkT3WOUHFyF64HBSg= X-Received: by 2002:a63:9501:: with SMTP id p1mr15002034pgd.149.1547760265539; Thu, 17 Jan 2019 13:24:25 -0800 (PST) Received: from localhost ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id b9sm3304218pfi.118.2019.01.17.13.24.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Jan 2019 13:24:24 -0800 (PST) Date: Thu, 17 Jan 2019 13:24:23 -0800 From: Guenter Roeck To: Rasmus Villemoes Cc: "linux-watchdog@vger.kernel.org" , Wim Van Sebroeck , Jonathan Corbet , "linux-kernel@vger.kernel.org" , "linux-doc@vger.kernel.org" , Esben Haabendal , "martin@hundeboll.net" , Rasmus Villemoes Subject: Re: [PATCH v8 1/3] watchdog: introduce watchdog.open_timeout commandline parameter Message-ID: <20190117212423.GA14108@roeck-us.net> References: <20190116121432.26732-1-rasmus.villemoes@prevas.dk> <20190116121432.26732-2-rasmus.villemoes@prevas.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190116121432.26732-2-rasmus.villemoes@prevas.dk> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 16, 2019 at 12:14:42PM +0000, 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. > > A value of 0 (the default) means infinite timeout, preserving the > current behaviour. > > 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, ...). > > There is already handle_boot_enabled serving a similar purpose. However, > such a binary choice is unsuitable if the hardware watchdog cannot be > programmed by the bootloader to provide a timeout long enough for > userspace to get up and running. Many of the embedded devices we see use > external (gpio-triggered) watchdogs with a fixed timeout of the order of > 1-2 seconds. > > The open timeout is also used as a maximum time for an application to > re-open /dev/watchdogN after closing it. Again, while the kernel already > has a nowayout mechanism, using that means userspace is at the mercy of > whatever timeout the hardware has. > > Being a module parameter, one can revert to the ordinary behaviour of > having the kernel maintain the watchdog indefinitely by simply writing 0 > to /sys/... after initially opening /dev/watchdog; conversely, one can > of course also have the current behaviour of allowing indefinite time > until the first open, and then set that module parameter. > > The unit is milliseconds rather than seconds because that covers more > use cases. For example, userspace might need a long time to get in the > air initially, requiring a somewhat liberal open_timeout, but when (for > whatever reason) the application might then want to re-exec itself, it > can set a much smaller threshold. > I don't buy this use case. We are not in control of the exact time between hand-off to the Linux kernel and to driver instantiation, and we can not even measure it. A less-than-one second granularity, especially since it is from instantiation time and not even from handoff time, does not really make sense and would only create a false impression of accuracy. Let's stick with seconds. Guenter > Signed-off-by: Rasmus Villemoes > --- > .../watchdog/watchdog-parameters.txt | 8 +++++ > drivers/watchdog/watchdog_dev.c | 30 +++++++++++++++++-- > 2 files changed, 36 insertions(+), 2 deletions(-) > > diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt > index 0b88e333f9e1..5e4235989154 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 f6c24b22b37c..a9585925458f 100644 > --- a/drivers/watchdog/watchdog_dev.c > +++ b/drivers/watchdog/watchdog_dev.c > @@ -69,6 +69,7 @@ struct watchdog_core_data { > struct mutex lock; > ktime_t last_keepalive; > ktime_t last_hw_keepalive; > + ktime_t open_deadline; > struct hrtimer timer; > struct kthread_work work; > unsigned long status; /* Internal status bits */ > @@ -87,6 +88,19 @@ static struct kthread_worker *watchdog_kworker; > static bool handle_boot_enabled = > IS_ENABLED(CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED); > > +static unsigned open_timeout; > + > +static bool watchdog_past_open_deadline(struct watchdog_core_data *data) > +{ > + return ktime_after(ktime_get(), data->open_deadline); > +} > + > +static void watchdog_set_open_deadline(struct watchdog_core_data *data) > +{ > + data->open_deadline = open_timeout ? > + ktime_get() + ms_to_ktime(open_timeout) : KTIME_MAX; > +} > + > static inline bool watchdog_need_worker(struct watchdog_device *wdd) > { > /* All variables in milli-seconds */ > @@ -211,7 +225,13 @@ static bool watchdog_worker_should_ping(struct watchdog_core_data *wd_data) > { > struct watchdog_device *wdd = wd_data->wdd; > > - return wdd && (watchdog_active(wdd) || watchdog_hw_running(wdd)); > + if (!wdd) > + return false; > + > + if (watchdog_active(wdd)) > + return true; > + > + return watchdog_hw_running(wdd) && !watchdog_past_open_deadline(wd_data); > } > > static void watchdog_ping_work(struct kthread_work *work) > @@ -297,7 +317,7 @@ static int watchdog_stop(struct watchdog_device *wdd) > return -EBUSY; > } > > - if (wdd->ops->stop) { > + if (wdd->ops->stop && !open_timeout) { > clear_bit(WDOG_HW_RUNNING, &wdd->status); > err = wdd->ops->stop(wdd); > } else { > @@ -883,6 +903,7 @@ static int watchdog_release(struct inode *inode, struct file *file) > watchdog_ping(wdd); > } > > + watchdog_set_open_deadline(wd_data); > watchdog_update_worker(wdd); > > /* make sure that /dev/watchdog can be re-opened */ > @@ -983,6 +1004,7 @@ static int watchdog_cdev_register(struct watchdog_device *wdd, dev_t devno) > > /* Record time of most recent heartbeat as 'just before now'. */ > wd_data->last_hw_keepalive = ktime_sub(ktime_get(), 1); > + watchdog_set_open_deadline(wd_data); > > /* > * If the watchdog is running, prevent its driver from being unloaded, > @@ -1181,3 +1203,7 @@ module_param(handle_boot_enabled, bool, 0444); > MODULE_PARM_DESC(handle_boot_enabled, > "Watchdog core auto-updates boot enabled watchdogs before userspace takes over (default=" > __MODULE_STRING(IS_ENABLED(CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED)) ")"); > + > +module_param(open_timeout, uint, 0644); > +MODULE_PARM_DESC(open_timeout, > + "Maximum time (in milliseconds, 0 means infinity) for userspace to take over a running watchdog (default=0)"); > -- > 2.20.1 >