It is possible that schedule(), and hence cyclic_run(), gets called
very early, perhaps even from assembly code. With commit
9c1b13b3fd2 ("cyclic: reduce get_timer_us() calls inside
hlist_for_each_entry_safe()"), there is now an unconditional
get_timer_us(0) done outside the loop, and depending on the platform,
the timer infrastructure may not be set up yet. In at least one case,
that has caused a divide-by-0 and hence a failure to boot.

Platforms should really ensure their timers are ready ASAP, and in the
concrete case reported, that was indeed possible to fix that
way. However, it doesn't hurt to also insert an early return here, and
that could prevent other such hard-to-debug boot failures.

Reported-by: Emanuele Ghidoli <[email protected]>
Link: https://marc.info/?l=u-boot&m=178481834846283&w=2
Fixes: 9c1b13b3fd2 ("cyclic: reduce get_timer_us() calls inside 
hlist_for_each_entry_safe()")
Signed-off-by: Rasmus Villemoes <[email protected]>
---
 common/cyclic.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/common/cyclic.c b/common/cyclic.c
index 2bc3c773f27..232143171ab 100644
--- a/common/cyclic.c
+++ b/common/cyclic.c
@@ -63,6 +63,19 @@ static void cyclic_run(void)
        struct hlist_node *tmp;
        u64 now, after, cpu_time;
 
+       /*
+        * Nothing to do if the list is empty. Also, schedule() can be
+        * called before timer infrastructure is ready, in which case
+        * calling get_timer_us() before the (empty) loop could cause
+        * a divide-by-0 or otherwise crash the system. No clients
+        * should be registered before the timer infrastructure is up,
+        * so the check for the list being empty should be
+        * ok. Otherwise, we would need a new GD_FLG_TIMERS_READY
+        * flag.
+        */
+       if (hlist_empty(&gd->cyclic_list))
+                return;
+
        /* Prevent recursion */
        if (gd->flags & GD_FLG_CYCLIC_RUNNING)
                return;
-- 
2.55.0

Reply via email to