kernel.git/drivers/watchdog/watchdog_dev.c, branch linux-6.1.y

watchdog: set cdev owner before adding

2024-01-25T23:27:36Z

[ Upstream commit 38d75297745f04206db9c29bdd75557f0344c7cc ] When the new watchdog character device is registered, it becomes available for opening. This creates a race where userspace may open the device before the character device's owner is set. This results in an imbalance in module_get calls as the cdev_get in cdev_open will not increment the reference count on the watchdog driver module. This causes problems when the watchdog character device is released as the module loader's reference will also be released. This makes it impossible to open the watchdog device later on as it now appears that the module is being unloaded. The open will fail with -ENXIO from chrdev_open. The legacy watchdog device will fail with -EBUSY from the try_module_get in watchdog_open because it's module owner is the watchdog core module so it can still be opened but it will fail to get a refcount on the underlying watchdog device driver. Fixes: 72139dfa2464 ("watchdog: Fix the race between the release of watchdog_core_data and cdev") Signed-off-by: Curtis Klein Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20231205190522.55153-1-curtis.klein@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin

watchdog: Fix kmemleak in watchdog_cdev_register

2023-03-11T12:55:23Z

[ Upstream commit 13721a2ac66b246f5802ba1b75ad8637e53eeecc ] kmemleak reports memory leaks in watchdog_dev_register, as follows: unreferenced object 0xffff888116233000 (size 2048): comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s) hex dump (first 32 bytes): 80 fa b9 05 81 88 ff ff 08 30 23 16 81 88 ff ff .........0#..... 08 30 23 16 81 88 ff ff 00 00 00 00 00 00 00 00 .0#............. backtrace: [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220 [<000000006a389304>] kmalloc_trace+0x21/0x110 [<000000008d640eea>] watchdog_dev_register+0x4e/0x780 [watchdog] [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog] [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog] [<000000001f730178>] 0xffffffffc10880ae [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0 [<00000000b98be325>] do_init_module+0x1ca/0x5f0 [<0000000046d08e7c>] load_module+0x6133/0x70f0 ... unreferenced object 0xffff888105b9fa80 (size 16): comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s) hex dump (first 16 bytes): 77 61 74 63 68 64 6f 67 31 00 b9 05 81 88 ff ff watchdog1....... backtrace: [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220 [<00000000486ab89b>] __kmalloc_node_track_caller+0x44/0x1b0 [<000000005a39aab0>] kvasprintf+0xb5/0x140 [<0000000024806f85>] kvasprintf_const+0x55/0x180 [<000000009276cb7f>] kobject_set_name_vargs+0x56/0x150 [<00000000a92e820b>] dev_set_name+0xab/0xe0 [<00000000cec812c6>] watchdog_dev_register+0x285/0x780 [watchdog] [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog] [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog] [<000000001f730178>] 0xffffffffc10880ae [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0 [<00000000b98be325>] do_init_module+0x1ca/0x5f0 [<0000000046d08e7c>] load_module+0x6133/0x70f0 ... The reason is that put_device is not be called if cdev_device_add fails and wdd->id != 0. watchdog_cdev_register wd_data = kzalloc [1] err = dev_set_name [2] .. err = cdev_device_add if (err) { if (wdd->id == 0) { // wdd->id != 0 .. } return err; // [1],[2] would be leaked To fix it, call put_device in all wdd->id cases. Fixes: 72139dfa2464 ("watchdog: Fix the race between the release of watchdog_core_data and cdev") Signed-off-by: Chen Jun Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20221116012714.102066-1-chenjun102@huawei.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin

watchdog: Add tracing events for the most usual watchdog events

2022-10-12T07:47:02Z

To simplify debugging which process touches a watchdog and when, add tracing events for .start(), .set_timeout(), .ping() and .stop(). Signed-off-by: Uwe Kleine-König Reviewed-by: Steven Rostedt (Google) Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20221008174602.3972859-1-u.kleine-koenig@pengutronix.de Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck

watchdog: Check dev_set_name() return value

2022-10-02T10:55:38Z

It's possible that dev_set_name() returns -ENOMEM, catch and handle this. Signed-off-by: Bo Liu Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20220920020312.2383-1-liubo03@inspur.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck

watchdog: Improve watchdog_dev function documentation

2022-03-27T15:04:08Z

Adjust function comments to the kernel doc format. It also adjusts some variable names and adds return values. No functional change. Changes from V1: Change "Returns" to "Return:" (Randy Dunlap) Cc: Wim Van Sebroeck Cc: Guenter Roeck Cc: Randy Dunlap Cc: linux-watchdog@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Daniel Bristot de Oliveira Tested-by: Randy Dunlap Acked-by: Randy Dunlap Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/30378a03e9cd9b5f6e92ec9bf512edc38bad8627.1644589712.git.bristot@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck

watchdog: Start watchdog in watchdog_set_last_hw_keepalive only if appropriate

2021-08-22T08:28:12Z

We must not pet a running watchdog when handle_boot_enabled is off because this will kick off automatic triggering before userland is running, defeating the purpose of the handle_boot_enabled control. Furthermore, don't ping in case watchdog_set_last_hw_keepalive was called incorrectly when the hardware watchdog is actually not running. Fixed: cef9572e9af3 ("watchdog: add support for adjusting last known HW keepalive time") Signed-off-by: Jan Kiszka Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/93d56386-6e37-060b-55ce-84de8cde535f@web.de Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck

watchdog: introduce watchdog_dev_suspend/resume

2021-08-22T08:28:08Z

The watchdog drivers often disable wdog clock during suspend and then enable it again during resume. Nevertheless the ping worker is still running and can issue low-level ping while the wdog clock is disabled causing the system hang. To prevent such condition register pm notifier in the watchdog core which will call watchdog_dev_suspend/resume and actually cancel ping worker during suspend and restore it back, if needed, during resume. Signed-off-by: Grzegorz Jaszczyk Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20210618195033.3209598-2-grzegorz.jaszczyk@linaro.org Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck

watchdog: Fix NULL pointer dereference when releasing cdev

2021-08-22T08:28:07Z

watchdog_hrtimer_pretimeout_stop needs the watchdog device to have a valid pointer to the watchdog core data to stop the pretimeout hrtimer. Therefore it needs to be called before the pointers are cleared in watchdog_cdev_unregister. Fixes: 7b7d2fdc8c3e ("watchdog: Add hrtimer-based pretimeout feature") Reported-by: Colin Ian King Signed-off-by: Curtis Klein Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/1624429583-5720-1-git-send-email-curtis.klein@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck

watchdog: only run driver set_pretimeout op if device supports it

2021-08-22T08:28:07Z

Some watchdog devices might conditionally support pretimeouts (e.g. if an interrupt is exposed for the device) but some watchdog drivers might still define the set_pretimeout operation (e.g. the mtk_wdt driver) and indicate support at runtime through the WDIOF_PRETIMEOUT flag. If the kernel is compiled with CONFIG_WATCHDOG_HRTIMER_PRETIMEOUT enabled, watchdog_set_pretimeout would run the driver specific set_pretimeout even if WDIOF_PRETIMEOUT is not set which might have unintended consequences. So this change checks that the device flags and only runs the driver operation if pretimeouts are supported. Signed-off-by: Curtis Klein Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/1624751265-24785-1-git-send-email-curtis.klein@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck

watchdog: Add hrtimer-based pretimeout feature

2021-06-21T06:49:13Z

This adds the option to use a hrtimer to generate a watchdog pretimeout event for hardware watchdogs that do not natively support watchdog pretimeouts. With this enabled, all watchdogs will appear to have pretimeout support in userspace. If no pretimeout value is set, there will be no change in the watchdog's behavior. If a pretimeout value is set for a specific watchdog that does not have built-in pretimeout support, a timer will be started that should fire at the specified time before the watchdog timeout would occur. When the watchdog is successfully pinged, the timer will be restarted. If the timer is allowed to fire it will generate a pretimeout event. However because a software timer is used, it may not be able to fire in every circumstance. If the watchdog does support a pretimeout natively, that functionality will be used instead of the hrtimer. The general design of this feaure was inspired by the software watchdog, specifically its own pretimeout implementation. However the software watchdog and this feature are completely independent. They can be used together; with or without CONFIG_SOFT_WATCHDOG_PRETIMEOUT enabled. The main advantage of using the hrtimer pretimeout with a hardware watchdog, compared to running the software watchdog with a hardware watchdog, is that if the hardware watchdog driver is unable to ping the watchdog (e.g. due to a bus or communication error), then the hrtimer pretimeout would still fire whereas the software watchdog would not. Signed-off-by: Curtis Klein Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/1612383090-27110-1-git-send-email-curtis.klein@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck