From: Lars-Peter Clausen <lars@metafoo.de>
To: Wim Van Sebroeck <wim@iguana.be>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux Watchdog Mailing List <linux-watchdog@vger.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH 01/11] watchdog: WatchDog Timer Driver Core - Add basic framework
Date: Tue, 12 Jul 2011 01:00:25 +0200 [thread overview]
Message-ID: <4E1B8089.90103@metafoo.de> (raw)
In-Reply-To: <1310392522-9949-1-git-send-email-wim@iguana.be>
On 07/11/2011 04:19 PM, Wim Van Sebroeck wrote:
> [...]
> +
> +
> +static int watchdog_release(struct inode *inode, struct file *file)
> +{
> + int err;
> +
> + /* stop the watchdog */
> + err = wdd->ops->stop(wdd);
Does it really make sense to allow stop() to fail? Will this ever happen, and
if yes do we gain anything by sending a additional ping?
> + if (err != 0) {
> + pr_crit("%s: watchdog did not stop!\n", wdd->info->identity);
> + watchdog_ping(wdd);
> + }
> +
> + /* Allow the owner module to be unloaded again */
> + module_put(wdd->ops->owner);
> +
> + /* make sure that /dev/watchdog can be re-opened */
> + clear_bit(WDOG_DEV_OPEN, &wdd->status);
> +
> + return 0;
> +}
> +
> [...]
> +
> +int watchdog_dev_unregister(struct watchdog_device *watchdog)
> +{
> + /* Check that a watchdog device was registered in the past */
> + if (!test_bit(0, &watchdog_dev_busy) || !wdd)
> + return -ENODEV;
> +
> + /* We can only unregister the watchdog device that was registered */
> + if (watchdog != wdd) {
> + pr_err("%s: watchdog was not registered as /dev/watchdog.\n",
> + watchdog->info->identity);
> + return -ENODEV;
> + }
> +
> + /* Unregister the miscdevice */
> + misc_deregister(&watchdog_miscdev);
> + wdd = NULL;
> + clear_bit(0, &watchdog_dev_busy);
> + return 0;
> +}
What happens if the watchdog gets unregistered if the device is still opened?
Even though if you'd check wdd for not being NULL in the file callbacks there
is still a chance for races if the devices is unregistered at the same time as
the callback is running. You'd either need a big lock to protect from having a
file callback and unregister running concurrently or add ref-counting to the
watchdog_device, the later best done by embedding a struct device and using the
device driver model.
> +
> +MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);
> diff --git a/drivers/watchdog/watchdog_dev.h b/drivers/watchdog/watchdog_dev.h
> new file mode 100644
> index 0000000..bc7612b
> --- /dev/null
> +++ b/drivers/watchdog/watchdog_dev.h
> @@ -0,0 +1,33 @@
> [...]
>
> +struct watchdog_ops;
> +struct watchdog_device;
> +
> +/* The watchdog-devices operations */
> +struct watchdog_ops {
> + struct module *owner;
> + /* mandatory operations */
> + int (*start)(struct watchdog_device *);
> + int (*stop)(struct watchdog_device *);
> + /* optional operations */
> + int (*ping)(struct watchdog_device *);
> +};
> +
> +/* The structure that defines a watchdog device */
> +struct watchdog_device {
> + const struct watchdog_info *info;
> + const struct watchdog_ops *ops;
> + void *priv;
You should provide getter/setter methods for priv, so that when the watchdog
API is changed to make use of the device driver model it becomes easier to get
rid of the priv field and use dev_{get,set}_drvdata instead.
> + unsigned long status;
> +/* Bit numbers for status flags */
> +#define WDOG_DEV_OPEN 1 /* Opened via /dev/watchdog ? */
> +};
Kernel-doc style documentation for the structs would be nice.
> +
> +/* drivers/watchdog/core/watchdog_core.c */
> +extern int watchdog_register_device(struct watchdog_device *);
> +extern void watchdog_unregister_device(struct watchdog_device *);
> +
> #endif /* __KERNEL__ */
>
> #endif /* ifndef _LINUX_WATCHDOG_H */
next prev parent reply other threads:[~2011-07-11 23:02 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-11 13:50 [PATCH 0/11 v3] Generic Watchdog Timer Driver Wim Van Sebroeck
2011-07-11 14:19 ` [PATCH 01/11] watchdog: WatchDog Timer Driver Core - Add basic framework Wim Van Sebroeck
2011-07-11 14:21 ` [PATCH 02/11] watchdog: WatchDog Timer Driver Core - Add basic ioctl functionality Wim Van Sebroeck
2011-07-11 21:32 ` Wolfram Sang
2011-07-11 14:21 ` [PATCH 03/11] watchdog: WatchDog Timer Driver Core - Add WDIOC_KEEPALIVE ioctl Wim Van Sebroeck
2011-07-11 14:22 ` [PATCH 04/11] watchdog: WatchDog Timer Driver Core - Add WDIOC_SETOPTIONS ioctl Wim Van Sebroeck
2011-07-11 21:32 ` Wolfram Sang
2011-07-22 19:26 ` Wim Van Sebroeck
2011-07-11 14:22 ` [PATCH 05/11] watchdog: WatchDog Timer Driver Core - Add WDIOC_SETTIMEOUT and WDIOC_GETTIMEOUT ioctl Wim Van Sebroeck
2011-07-11 21:34 ` Wolfram Sang
2011-07-11 14:22 ` [PATCH 06/11] watchdog: WatchDog Timer Driver Core - Add Magic Close feature Wim Van Sebroeck
2011-07-11 21:35 ` Wolfram Sang
2011-07-11 14:23 ` [PATCH 07/11] watchdog: WatchDog Timer Driver Core - Add nowayout feature Wim Van Sebroeck
2011-07-11 14:23 ` [PATCH 09/11] watchdog: WatchDog Timer Driver Core - Add ioctl call Wim Van Sebroeck
2011-07-11 14:24 ` [PATCH 08/11] watchdog: WatchDog Timer Driver Core - Add parent device Wim Van Sebroeck
2011-07-11 14:24 ` [PATCH 10/11] watchdog: WatchDog Timer Driver Core - Add minimum and max timeout Wim Van Sebroeck
2011-07-11 14:24 ` [PATCH 11/11] watchdog: WatchDog Timer Driver Core - Remove llseek Wim Van Sebroeck
2011-07-11 21:35 ` Wolfram Sang
2011-07-11 21:48 ` Arnd Bergmann
2011-07-11 21:32 ` [PATCH 01/11] watchdog: WatchDog Timer Driver Core - Add basic framework Wolfram Sang
2011-07-11 23:02 ` Lars-Peter Clausen
2011-07-22 19:24 ` Wim Van Sebroeck
2011-07-11 23:00 ` Lars-Peter Clausen [this message]
2011-07-11 23:53 ` Mark Brown
2011-07-12 9:24 ` Alan Cox
2011-07-22 19:32 ` Wim Van Sebroeck
2011-07-24 3:58 ` Lars-Peter Clausen
2011-07-27 20:24 ` Wim Van Sebroeck
2011-07-29 9:24 ` Lars-Peter Clausen
2011-08-04 20:25 ` Wim Van Sebroeck
2011-07-11 21:31 ` [PATCH 0/11 v3] Generic Watchdog Timer Driver Wolfram Sang
2011-07-22 19:18 ` Wim Van Sebroeck
2011-07-22 19:38 ` Wim Van Sebroeck
2011-07-27 20:15 ` [PATCH 0/9 v4] " Wim Van Sebroeck
2011-07-27 20:16 ` [PATCH 1/9] watchdog: WatchDog Timer Driver Core - Add basic framework Wim Van Sebroeck
2011-07-27 20:16 ` [PATCH 2/9] watchdog: WatchDog Timer Driver Core - Add basic ioctl functionality Wim Van Sebroeck
2011-07-27 20:16 ` [PATCH 3/9] watchdog: WatchDog Timer Driver Core - Add WDIOC_KEEPALIVE ioctl Wim Van Sebroeck
2011-07-27 20:16 ` [PATCH 4/9] watchdog: WatchDog Timer Driver Core - Add WDIOC_SETOPTIONS ioctl Wim Van Sebroeck
2011-07-27 20:16 ` [PATCH 5/9] watchdog: WatchDog Timer Driver Core - Add WDIOC_SETTIMEOUT and WDIOC_GETTIMEOUT ioctl Wim Van Sebroeck
2011-07-27 20:16 ` [PATCH 6/9] watchdog: WatchDog Timer Driver Core - Add Magic Close feature Wim Van Sebroeck
2011-07-27 20:16 ` [PATCH 7/9] watchdog: WatchDog Timer Driver Core - Add nowayout feature Wim Van Sebroeck
2011-07-27 20:16 ` [PATCH 8/9] watchdog: WatchDog Timer Driver Core - Add ioctl call Wim Van Sebroeck
2011-07-27 20:16 ` [PATCH 9/9] watchdog: WatchDog Timer Driver Core - Add minimum and max timeout Wim Van Sebroeck
2011-07-28 21:29 ` [PATCH 1/9] watchdog: WatchDog Timer Driver Core - Add basic framework Joe Perches
2011-07-30 8:40 ` Arnd Bergmann
2011-07-12 18:43 ` [PATCH 0/11 v3] Generic Watchdog Timer Driver Arnd Bergmann
2011-07-22 20:48 ` Arnaud Lacombe
2011-07-22 21:31 ` Wim Van Sebroeck
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=4E1B8089.90103@metafoo.de \
--to=lars@metafoo.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--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