| Age | Commit message (Collapse) | Author |
|---|
|
some of these ought to have been noticed by the "misspell" tool,
so if anybody is debugging it, here are some bug reports :)
|
|
|
|
|
|
|
|
Now that half the threads are permissive and half are strict, we
need to make sure we have at least two threads, so that we'll
have at least one of each kind.
|
|
Fixes bug 22883.
|
|
|
|
now it looks like the other time we call it
|
|
|
|
Closes ticket 22356
|
|
I'll be using this in the unit tests for consdiffmgr.
|
|
|
|
|
|
Previously we freed the old "keys" object, but leaked the
worker_state_t that we had taken it from.
Fixes bug 20401; bugfix on 0.2.6.3-alpha.
|
|
This commit adds or improves the module-level documenation for:
buffers.c circuitstats.c command.c connection_edge.c control.c
cpuworker.c crypto_curve25519.c crypto_curve25519.h
crypto_ed25519.c crypto_format.c dircollate.c dirserv.c dns.c
dns_structs.h fp_pair.c geoip.c hibernate.c keypin.c ntmain.c
onion.c onion_fast.c onion_ntor.c onion_tap.c periodic.c
protover.c protover.h reasons.c rephist.c replaycache.c
routerlist.c routerparse.c routerset.c statefile.c status.c
tor_main.c workqueue.c
In particular, I've tried to explain (for each documented module)
what each module does, what's in it, what the big idea is, why it
belongs in Tor, and who calls it. In a few cases, I've added TODO
notes about refactoring opportunities.
I've also renamed an argument, and fixed a few DOCDOC comments.
|
|
Only some very ancient distributions don't ship with Libevent 2 anymore,
even the oldest supported Ubuntu LTS version has it. This allows us to
get rid of a lot of compat code.
|
|
|
|
This includes a small refactoring to use a new enum (workqueue_reply_t)
for the return values instead of just ints.
|
|
|
|
|
|
Fixes bug 15245; bugfix on 0.2.6.3-alpha. Thanks to anonym for reporting!
|
|
Also remove the unit test mocks that allowed get_options() to be
NULL; that's an invariant violation for get_options().
|
|
The issue is that we use the cpuworker system with relays only, so if we
start up as a client and transition to being a relay later, we'll be
sad.
This fixes bug 14901; not in any released version of Tor.
|
|
These were suggested by dgoulet, thanks!
|
|
This fixes a bug where we decide to free the circuit because it isn't on
any workqueue anymore, and then the job finishes and the circuit gets
freed again.
Fixes bug #14815, not in any released version of Tor.
|
|
David Goulet finds that when he runs a busy relay for a while with the
latest version of the git code, the number of onionskins handled
slowly dwindles to zero, with total_pending_tasks wedged at its
maximum value.
I conjecture this is because the total_pending_tasks variable isn't
decremented when we successfully cancel a job. Fixed that.
Fixes bug 14741; bugfix not on any released version of tor.
|
|
|
|
|
|
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
|
|
Previously I used one queue per worker; now I use one queue for
everyone. The "broadcast" code is gone, replaced with an idempotent
'update' operation.
|
|
The solution I took is to not free a circuit with a pending
uncancellable work item, but rather to set its magic number to a
sentinel value. When we get a work item, we check whether the circuit
has that magic sentinel, and if so, we free it rather than processing
the reply.
|
|
To avoid having diffs turn out too big, I had replaced some unneeded
ifs and fors with if (1), so that the indentation would still work out
right. Now I might as well clean those up.
|
|
|
|
|
|
|
|
Because in 95 years, we or our successors will surely care about
enforcing the BSD license terms on this code. Right?
|
|
|
|
Long ago we supported systems where there was no support for
threads, or where the threading library was broken. We shouldn't
have do that any more: on every OS that matters, threads exist, and
the OS supports running threads across multiple CPUs.
This resolves tickets 9495 and 12439. It's a prerequisite to making
our workqueue code work better, since sensible workqueue
implementations don't split across multiple processes.
|
|
|
|
scan-build doesn't realize that a request can't be timed at the end
unless it's timed at the start, and so it's not possible for us to
be subtracting start from end without start being set.
Nevertheless, let's not confuse it.
|
|
This improves the accuracy of the function/variable names.
|
|
If we don't, we can wind up with a wedged cpuworker, and write to it
for ages and ages.
Found by skruffy. This was a bug in 2dda97e8fd898757, a.k.a. svn
revision 402. It's been there since we have been using cpuworkers.
|
|
we skip onionskins that came from non-relays, so we're less likely to
run into privacy troubles.
starts to implement ticket 9658.
|
|
(Based on a patch from flupzor; bug #8206)
|
|
Now that circid_t is 4 bytes long, the default integer promotions will
leave it alone when sizeof(int) == 4, which will leave us formatting an
unsigned as an int. That's technically undefined behavior.
Fixes bug 8447 on bfffc1f0fc7616a25c32da2eb759dade4651659e. Bug not
in any released Tor.
|
|
Conflicts:
src/or/channel.h
src/or/connection_or.c
src/or/cpuworker.c
|
|
When we compute the estimated microseconds we need to handle our
pending onionskins, we could (in principle) overflow a uint32_t if
we ever had 4 million pending onionskins before we had any data
about how onionskins take. Nevertheless, let's compute it properly.
Fixes bug 8210; bugfix on 0.2.4.10. Found by coverity; this is CID
980651.
|
|
We need a weak RNG in a couple of places where the strong RNG is
both needless and too slow. We had been using the weak RNG from our
platform's libc implementation, but that was problematic (because
many platforms have exceptionally horrible weak RNGs -- like, ones
that only return values between 0 and SHORT_MAX) and because we were
using it in a way that was wrong for LCG-based weak RNGs. (We were
counting on the low bits of the LCG output to be as random as the
high ones, which isn't true.)
This patch adds a separate type for a weak RNG, adds an LCG
implementation for it, and uses that exclusively where we had been
using the platform weak RNG.
|
|
|
|
|
