David Goulet [Mon, 18 Sep 2017 14:47:05 +0000 (10:47 -0400)]
sched: Don't cast to int32_t the monotime_diff_msec() result
When the KIST schedule() is called, it computes a diff value between the last
scheduler run and the current monotonic time. If tha value is below the run
interval, the libevent even is updated else the event is run.
It turned out that casting to int32_t the returned int64_t value for the very
first scheduler run (which is set to 0) was creating an overflow on the 32 bit
value leading to adding the event with a gigantic usec value. The scheduler
was simply never running for a while.
First of all, a BUG() is added for a diff value < 0 because if the time is
really monotonic, we should never have a now time that is lower than the last
scheduler run time. And we will try to recover with a diff value to 0.
Second, the diff value is changed to int64_t so we avoid this "bootstrap
overflow" and future casting overflow problems.
Fixes #23558
Signed-off-by: David Goulet <dgoulet@torproject.org>
Nick Mathewson [Mon, 18 Sep 2017 00:42:28 +0000 (20:42 -0400)]
Fix memory leak in tor-gencert.c
This was introduced in 4ff170d7b1cbe4074cb852, and is probably
unreachable, but coverity complained about it (CID 1417761). Bug not
in any released Tor, so no changes file.
Nick Mathewson [Fri, 15 Sep 2017 18:30:19 +0000 (14:30 -0400)]
kist: Cast, then do operations on int32.
Otherwise integer overflows can happen. Remember, doing a i32xi32
multiply doesn't actually produce a 64-bit output. You need to do
i64xi32 or i64xi64.
David Goulet [Thu, 14 Sep 2017 17:29:05 +0000 (13:29 -0400)]
sched: Always call on_channel_free() regardless of state
A channel can bounce in the scheduler and bounce out with the IDLE state which
means that if it came in the scheduler once, it has socket information that
needs to be freed from the global hash table.
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Thu, 14 Sep 2017 17:23:43 +0000 (13:23 -0400)]
sched: Add Schedulers torrc option
This option is a list of possible scheduler type tor can use ordered by
priority. Its default value is "KIST,KISTLite,Vanilla" which means that KIST
will be used first and if unavailable will fallback to KISTLite and so on.
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Thu, 31 Aug 2017 14:41:14 +0000 (10:41 -0400)]
sched: Fallback to naive approach if no runtime KIST support
It is possible that tor was compiled with KIST support but the running kernel
has no support for it. In that case, fallback to a naive approach and flag
that we have no kernel support.
At this commit, if the kernel support is disabled, there are no ways to come
back from it other than restarting tor with a kernel that supporst KIST.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Matt Traudt [Mon, 10 Jul 2017 20:10:29 +0000 (16:10 -0400)]
sched: Groundwork before KIST implementation
- HT_FOREACH_FN defined in an additional place because nickm did that
in an old kist prototype
- Make channel_more_to_flush mockable for future sched tests
- Add empty scheduler_{vanilla,kist}.c files and put in include.am
Signed-off-by: David Goulet <dgoulet@torproject.org>
Matt Traudt [Mon, 10 Jul 2017 14:47:56 +0000 (10:47 -0400)]
sched: Remove vanilla sched options that will be going away
- massive change to src/tgest/test_options.c since the sched options
were added all over the place in it
- removing the sched options caused some tests to pass/fail in new ways
so I assumed current behavior is correct and made them pass again
- ex: "ConnLimit must be greater" lines
- ex: "Authoritative directory servers must" line
- remove test_options_validate__scheduler in prep for new sched tests
Signed-off-by: David Goulet <dgoulet@torproject.org>
Taylor Yu [Fri, 15 Sep 2017 01:43:52 +0000 (20:43 -0500)]
Make NETINFO clock skew detection work on clients
An unnecessary routerlist check in the NETINFO clock skew detection in
channel_tls_process_netinfo_cell() was preventing clients from
reporting NETINFO clock skew to controllers.
Nick Mathewson [Wed, 6 Sep 2017 20:26:47 +0000 (16:26 -0400)]
Fix several places where md-using relays would get wrong behavior.
This patch replaces a few calls to router_get_by_id_digest ("do we
have a routerinfo?") with connection_or_digest_is_known_relay ("do
we know this relay to be in the consensus, or have been there some
time recently?").
Found while doing the 21585 audit; fixes bug 23533. Bugfix on
0.3.0.1-alpha.