watchdog: ping frequency can exceed the timeout the driver accepted

Aperta
  • Qualcosa non va?
#57 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 4 giorni

@thc1006 ci sta già lavorando.

Dal 18/10/2026.

  • #58 di @thc1006 — aperta
  • #59 di @thc1006 — aperta

Valutazione

Difficoltà
1/5
Tempo stimato
Meno di un'ora
Idoneità per principianti
15/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
c, linux
Ambito
backend, embedded-iot

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
C
Stelle
13
Fork
49
Merge medio
11g 12h
PR unite (30g)
3

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di openwrt/procd

Tutte le issue di openwrt/procd

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.