watchdog: ping frequency can exceed the timeout the driver accepted
维护者通常 4 天内回复
评估
- 难度
- 1/5
- 预计耗时
- 1 小时以内
- 新手友好度
- 15/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 停滞
- 技术栈
- c, linux
- 领域
- backend, embedded-iot
调研方向
The issue points to the watchdog decision block in system.c (watchdog_set) and links the fix in #58. Read that handler and compare the accepted timeout with the frequency it selects; the issue’s softdog reproduction starts at 30 s and requests {"timeout":200000,"frequency":90000}. Done means the frequency is capped against the timeout the driver actually keeps, so this case leaves a 30 s timeout and 15 s frequency.
由索引模型根据 Issue 内容生成。
描述
Follow-up to #55, in the ubus handler (system.c:watchdog_set).
ubus call system watchdog can set the timeout and the ping frequency in one call. The handler caps the frequency at half the timeout, but it does that against the timeout the caller requested, and before the timeout is applied. When the driver cannot accept the requested timeout (EINVAL, for example above 107 s on rt2880_wdt at 40 MHz), the timeout keeps its old value. The frequency can still be as high as half the requested timeout. If that frequency is larger than the timeout now in force, procd pings less often than the timeout requires and the board can reset while it is still running.
#55 did not cause this. Before it the handler reported the requested timeout, so the timeout and frequency it returned still looked consistent; now it reports the timeout in force, so the mismatch shows.
How I saw it, on x86-64 with GCC 13.3.0: I copied the handler's decision block, old and new, out of system.c and ran both against a real softdog, with watchdog.c from main. softdog was loaded with soft_noboot=1, so an expiry is only logged. It refuses any timeout above 65535 s. From a 30 s timeout, {"timeout":200000,"frequency":90000} leaves a 30 s timeout and a 90000 s frequency with the current code. Re-checking the frequency against the timeout the driver kept leaves 30 s and 15 s.
Setting the watchdog over ubus is normally a root operation, so the effect is a misconfiguration that can reset a live board.
The fix is in #58.
- 主要语言
- C
- 星标
- 13
- 派生
- 49
- 平均合并
- 11 天 12 小时
- 30 天内合并 PR
- 3
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
openwrt/procd 的其他 Issue
-
难度 3/5 1-2 天 新手友好度 68/100
维护者通常 4 天内回复
-
难度 4/5 3-5 天 新手友好度 48/100
维护者通常 4 天内回复
-
难度 4/5 3-5 天 新手友好度 48/100
维护者通常 4 天内回复
-
难度 4/5 3-5 天 新手友好度 35/100
维护者通常 4 天内回复
-
难度 4/5 3-5 天 新手友好度 30/100
维护者通常 4 天内回复
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 78/100
FujiNetWIFI/fujinet-config#379 ·
维护者通常 1 天内回复
-
Ship /Local/Applications, the Local domain's Applications folder可能已有人在做 @pkgdemon 今天认领。 未关闭area:base enhancement
难度 1/5 1 小时以内 新手友好度 94/100
nextbsd/nextbsd-userland#612 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
zephyrproject-rtos/zephyr#125543 ·
维护者通常 2 天内回复
-
good first issue needs-triage
难度 1/5 1 小时以内 新手友好度 88/100
InauguralSystems/EigenScript#2347 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
colbymchenry/codegraph#3277 ·
维护者通常 1 天内回复