[or-cvs] r9377: If our system clock jumps back in time, don't publish a nega (in tor/trunk: . src/or)
arma at seul.org
arma at seul.org
Sun Jan 21 06:24:09 UTC 2007
Author: arma
Date: 2007-01-21 01:24:05 -0500 (Sun, 21 Jan 2007)
New Revision: 9377
Modified:
tor/trunk/ChangeLog
tor/trunk/src/or/connection.c
tor/trunk/src/or/main.c
Log:
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.
Modified: tor/trunk/ChangeLog
===================================================================
--- tor/trunk/ChangeLog 2007-01-20 14:16:30 UTC (rev 9376)
+++ tor/trunk/ChangeLog 2007-01-21 06:24:05 UTC (rev 9377)
@@ -24,6 +24,9 @@
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
Modified: tor/trunk/src/or/connection.c
===================================================================
--- tor/trunk/src/or/connection.c 2007-01-20 14:16:30 UTC (rev 9376)
+++ tor/trunk/src/or/connection.c 2007-01-21 06:24:05 UTC (rev 9377)
@@ -1292,6 +1292,8 @@
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;
Modified: tor/trunk/src/or/main.c
===================================================================
--- tor/trunk/src/or/main.c 2007-01-20 14:16:30 UTC (rev 9376)
+++ tor/trunk/src/or/main.c 2007-01-21 06:24:05 UTC (rev 9377)
@@ -984,25 +984,21 @@
/* 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 @@
/** 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);
More information about the tor-commits
mailing list