The old approach, because of its "tmp >= rand_bw &&
!i_has_been_chosen" check, would run through the second part of the
loop slightly slower than the first part. Now, we remove
i_has_been_chosen, and instead set rand_bw = UINT64_MAX, so that
every instance of the loop will do exactly the same amount of work
regardless of the initial value of rand_bw.
Fix for bug 6538.
This should make our preferred solution to #6538 easier to
implement, avoid a bunch of potential nastiness with excessive
int-vs-double math, and generally make the code there a little less
scary.
"But wait!" you say. "Is it really safe to do this? Won't the
results come out differently?"
Yes, but not much. We now round every weighted bandwidth to the
nearest byte before computing on it. This will make every node that
had a fractional part of its weighted bandwidth before either
slighty more likely or slightly less likely. Further, the rand_bw
value was only ever set with integer precision, so it can't
accurately sample routers with tiny fractional bandwidth values
anyway. Finally, doing repeated double-vs-uint64 comparisons is
just plain sad; it will involve an implicit cast to double, which is
never a fun thing.
I don't personally agree that this is likely to be easy to exploit,
and some initial experimention I've done suggests that cache-miss
times are just plain too fast to get useful info out of when they're
mixed up with the rest of Tor's timing noise. Nevertheless, I'm
leaving Robert's initial changelog entry in the git history so that he
can be the voice of reason if I'm wrong. :)
$ make V=1 # will temporarily disable them
otherwise you see:
CC foo.c
rather than the giant long bulid line.
This makes it significantly easier to spot compiler warnings etc.
Additionally, make them conditional, so we won't error on automake <
1.11
(commits squashed by nickm.)
In 0.2.3.18-rc, we started warning on this case while building a
list of missing microdescriptor digests. That turned out to spam
the logs; instead let's warn at parse time.
Partial fix for bug 6404.
The spec requires that every router in a microdesc consensus have an
m line; we weren't obeying that spec.
This creates a new consensus method (13) to allow voting to continue
to work right. Partial fix for bug 6404; fix on 0.2.2.6-alpha.
This is based on a pair of patches from A. Costa. I couldn't apply
those directly, since they changed the generated *roff files, not
the asciidoc source.
Fixes Tor bug 6500 and Debian bug 683359.
Test for config option AuthDirPublishIPv6 == 1 rather than for running
as a bridge authority when deciding whether to care or not about IPv6
OR ports in descriptors.
Implements enhancement #6406.
This avoids a possible crash bug in flush_from_first_active_circuit.
Fixes bug 6341; bugfix on 0.2.2.7-alpha.
Bug reported and fixed by a pseudonymous user on IRC.
I only check on circuits, not streams, since bloating your stream
window past the initial circuit window can't help you much.
Also, I compare to CIRCWINDOW_START_MAX so we don't have surprising
races if we lower CIRCWINDOW_START for an experiment.
The SMARTLIST_FOREACH macro is more convenient than BEGIN/END when
you have a nice short loop body, but using it for long bodies makes
your preprocessor tell the compiler that all the code is on the same
line. That causes grief, since compiler warnings and debugger lines
will all refer to that one line.
So, here's a new style rule: SMARTLIST_FOREACH blocks need to be
short.