BUG/MINOR: clock: make time jump corrections a bit more accurate
authorWilly Tarreau <w@1wt.eu>
Thu, 12 Sep 2024 15:58:57 +0000 (17:58 +0200)
committerChristopher Faulet <cfaulet@haproxy.com>
Tue, 17 Sep 2024 07:27:01 +0000 (09:27 +0200)
Since commit e8b1ad4c2b ("BUG/MEDIUM: clock: also update the date offset
on time jumps") we try to update the now_offet based on the last known
valid date. But if it's off compared to the global_now_ns date shared
by other threads, we'll get the time off a little bit. When this happens,
we should consider the most recent of these dates so that if the global
date was already known to be more recent, we should use it and stick to
it. This will avoid setting too large an offset that could in turn provoke
a larger jump on another thread.

This is related to issue GH #2704.

This can be backported to other branches having the patch above.

(cherry picked from commit af48e4cc6b315cadb80d6980586af5c3c8368826)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>

src/clock.c

index 3b64b9b..041c9bf 100644 (file)
@@ -223,6 +223,9 @@ void clock_update_local_date(int max_wait, int interrupted)
                if (!interrupted)
                        now_ns += ms_to_ns(max_wait);
 
+               /* consider the most recent known date */
+               now_ns = MAX(now_ns, HA_ATOMIC_LOAD(&global_now_ns));
+
                /* this event is rare, but it requires proper handling because if
                 * we just left now_ns where it was, the date will not be updated
                 * by clock_update_global_date().