dangernoodle-io / breadboard / 30069551776

97%

push

github

fix: guard bb_wifi_ping/bb_timer/bb_mdns bootstrap with retryable fallible-once (race + OOM-safe) (B1-524) (#1046)

Unguarded check-create-assign of lazy-init state raced concurrent callers
(dual-core): bb_wifi_ping's ping mutex/sem, bb_timer's disp queue/task, and
bb_mdns_init's mutex/queue/task cascade (previously covered only by a
documented single-caller contract) could each be double-created or
partially assigned.

A first pass migrated all three onto bb_once_run() guarding a separate
bb_lock_t. Review caught two HIGH-severity regressions that pattern
introduces: bb_once_run() has no failure channel and latches DONE
unconditionally, so (1) a transient create failure on the ping mutex/sem
was permanently latched as BB_ERR_NO_MEM for the firmware's life (strict
regression vs. the old retrying code), and (2) guarding bb_lock_init()
itself (which also heap-allocates and can fail) with bb_once_run()
reproduces the same bug one level down: a failed lock init leaves an
uninitialized bb_lock_t latched "done" forever, and every later
bb_lock_lock() call dereferences a NULL semaphore -- a boot-time OOM
crash-loops the firmware permanently.

Fix: components/bb_core/include/bb_once.h gains bb_once_run_fallible(), a
sibling of bb_once_run() for a body that can fail -- fn returns bool; a
successful run latches DONE (never re-run again), a failed run resets the
guard back to IDLE so the very next caller genuinely retries, with the same
compare-exchange + spin/yield-wait mutual exclusion bb_once_run() already
uses. All three sites now run their fallible resource creation directly
inside a bb_once_run_fallible() body -- no intermediate bb_lock_t at all --
each still re-checking its own NULL sentinel(s) as defense-in-depth.
bb_mdns_init_locked()'s cascade body is otherwise unchanged; bb_mdns_init()
holding its own gate while nested-calling into bb_timer's independent gate
is a documented, declined liveness note (both are boot-time,
documented-single-caller composi... (continued)

7620 of 8217 branches covered (92.73%)

Branch coverage included in aggregate %.

15 of 15 new or added lines in 1 file covered. (100.0%)

12907 of 13065 relevant lines covered (98.79%)

2513.52 hits per line