From bcbd289af586af7fbc1c28a621988b09a60b913b Mon Sep 17 00:00:00 2001 From: Roger Dingledine Date: Sun, 21 Jan 2007 06:24:05 +0000 Subject: [PATCH] If our system clock jumps back in time, don't publish a negative uptime in the descriptor. Also, don't let the global rate limiting buckets go absurdly negative. svn:r9377 --- ChangeLog | 3 +++ src/or/connection.c | 2 ++ src/or/main.c | 21 ++++++++++----------- 3 files changed, 15 insertions(+), 11 deletions(-) diff --git a/ChangeLog b/ChangeLog index b9dea22b10..bc3e900a77 100644 --- a/ChangeLog +++ b/ChangeLog @@ -24,6 +24,9 @@ Changes in version 0.1.2.7-alpha - 2007-??-?? more directory responses, which can't be good for latency. - Be willing to read or write on local connections (e.g. controller connections) even when the global rate limiting buckets are empty. + - If our system clock jumps back in time, don't publish a negative + uptime in the descriptor. Also, don't let the global rate limiting + buckets go absurdly negative. o Minor bugfixes: - When computing clock skew from directory HTTP headers, consider what diff --git a/src/or/connection.c b/src/or/connection.c index 189a556fbe..5b31cec21d 100644 --- a/src/or/connection.c +++ b/src/or/connection.c @@ -1292,6 +1292,8 @@ connection_bucket_refill(int seconds_elapsed) connection_t **carray; or_options_t *options = get_options(); + tor_assert(seconds_elapsed >= 0); + /* refill the global buckets */ if (global_read_bucket < (int)options->BandwidthBurst) { global_read_bucket += (int)options->BandwidthRate*seconds_elapsed; diff --git a/src/or/main.c b/src/or/main.c index 1f082624c6..7833d6e378 100644 --- a/src/or/main.c +++ b/src/or/main.c @@ -984,25 +984,21 @@ second_elapsed_callback(int fd, short event, void *args) /* the second has rolled over. check more stuff. */ bytes_written = stats_prev_global_write_bucket - global_write_bucket; bytes_read = stats_prev_global_read_bucket - global_read_bucket; - /* XXX below we get suspicious if time jumps forward more than 10 - * seconds, but we never notice if it jumps *back* more than 10 seconds. - * This could be useful for detecting that we just NTP'ed to three - * weeks ago and it will be 3 weeks and 15 minutes until any of our - * events trigger. - */ seconds_elapsed = current_second ? (now.tv_sec - current_second) : 0; stats_n_bytes_read += bytes_read; stats_n_bytes_written += bytes_written; - if (accounting_is_enabled(options)) + if (accounting_is_enabled(options) && seconds_elapsed >= 0) accounting_add_bytes(bytes_read, bytes_written, seconds_elapsed); control_event_bandwidth_used((uint32_t)bytes_read,(uint32_t)bytes_written); - connection_bucket_refill(seconds_elapsed); + if (seconds_elapsed > 0) + connection_bucket_refill(seconds_elapsed); stats_prev_global_read_bucket = global_read_bucket; stats_prev_global_write_bucket = global_write_bucket; if (server_mode(options) && !we_are_hibernating() && + seconds_elapsed > 0 && stats_n_seconds_working / TIMEOUT_UNTIL_UNREACHABILITY_COMPLAINT != (stats_n_seconds_working+seconds_elapsed) / TIMEOUT_UNTIL_UNREACHABILITY_COMPLAINT) { @@ -1024,10 +1020,13 @@ second_elapsed_callback(int fd, short event, void *args) /** If more than this many seconds have elapsed, probably the clock * jumped: doesn't count. */ #define NUM_JUMPED_SECONDS_BEFORE_WARN 100 - if (seconds_elapsed < NUM_JUMPED_SECONDS_BEFORE_WARN) - stats_n_seconds_working += seconds_elapsed; - else + if (seconds_elapsed < -NUM_JUMPED_SECONDS_BEFORE_WARN || + seconds_elapsed >= NUM_JUMPED_SECONDS_BEFORE_WARN) { circuit_note_clock_jumped(seconds_elapsed); + /* XXX if the time jumps *back* many months, do our events in + * run_scheduled_events() recover? I don't think they do. -RD */ + } else if (seconds_elapsed > 0) + stats_n_seconds_working += seconds_elapsed; run_scheduled_events(now.tv_sec); -- 2.11.4.GIT