Isis Lovecruft [Thu, 8 Feb 2018 20:06:19 +0000 (20:06 +0000)]
rust: Add macro for passing static borrowed strings from Rust to C.
* ADD a new macro, tor_util::string::cstr!() which takes Rust strings,
concatenates them together, appends a NUL byte, and converts it into a
std::ffi::CStr for handing to C.
Nick Mathewson [Thu, 8 Feb 2018 22:26:26 +0000 (17:26 -0500)]
Remove new unsafe {} use.
Rationale: this helps for performance only, but we don't actually
have any reason to think that the checks here are
performance-critical. Let's not normalize the use of unsafe {}.
Isis Lovecruft [Tue, 6 Feb 2018 14:15:33 +0000 (14:15 +0000)]
protover: Fix memleak in Rust impl of protover_compute_for_old_tor.
* FIXES #25127: https://bugs.torproject.org/25127
* ADDS a new module to the Rust tor_util crate for small utilities
for working with static strings between languages.
* CHANGES the return type of protover_compute_for_old_tor to point to
immutable data.
* CHANGES the code from the previous commit to use the new static
string utilities.
Increase to 10 msec for now to address slow system. It is important that we
keep this OP_LE test in so we make sure the msec/usec/nsec read aren't
desynchronized by huge gaps. We'll adjust again if we ever encounter a system
that goes slower than 10 msec between calls.
Fixes #25113
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Tue, 6 Feb 2018 17:43:55 +0000 (12:43 -0500)]
rephist: Stop tracking EXTEND attempts
This removes the code that tracks the extend attemps a client makes. We don't
use it and it was only used to provide statistics on a SIGUSR1 from the
rephist dump stats function.
Part of #25163
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Mon, 5 Feb 2018 15:39:10 +0000 (10:39 -0500)]
geoip: Make geoip_client_cache_total_allocation() return the counter
The HT_FOREACH() is insanely heavy on the CPU and this is part of the fast
path so make it return the nice memory size counter we added in 4d812e29b9b1ec88.
Fixes #25148
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Fri, 2 Feb 2018 22:04:12 +0000 (17:04 -0500)]
dos: We can put less token than the current amount
Becasue the circuit creation burst and rate can change at runtime it is
possible that between two refill of a bucket, we end up setting the bucket
value to less than there currently is.
Fixes #25128
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Fri, 2 Feb 2018 13:48:34 +0000 (08:48 -0500)]
sched: When releasing a channel, do not BUG() if absent from the pending list
The current code flow makes it that we can release a channel in a PENDING
state but not in the pending list. This happens while the channel is being
processed in the scheduler loop.
Fixes #25125
Signed-off-by: David Goulet <dgoulet@torproject.org>
It appears that I misunderstood how the seccomp2 filter rules
interact. It appears that `SCMP_ACT_ERRNO()` always takes
precedence over `SCMP_ACT_ALLOW()` -- I had thought instead that
earlier rules would override later ones. But this change caused bug
25115 (not in any released Tor).
David Goulet [Wed, 31 Jan 2018 20:23:45 +0000 (15:23 -0500)]
circ: Don't cannibalize a circuit if the guard state is unusable
Tor preemptiely builds circuits and they can be cannibalized later in their
lifetime. A Guard node can become unusable (from our guard state) but we can
still have circuits using that node opened. It is important to not pick those
circuits for any usage through the cannibalization process.
Fixes #24469
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Wed, 31 Jan 2018 19:15:02 +0000 (14:15 -0500)]
ns: Add a before and after consensus has changed notification
In 0.3.2.1-alpha, we've added notify_networkstatus_changed() in order to have
a way to notify other subsystems that the consensus just changed. The old and
new consensus are passed to it.
Before this patch, this was done _before_ the new consensus was set globally
(thus NOT accessible by getting the latest consensus). The scheduler
notification was assuming that it was set and select_scheduler() is looking at
the latest consensus to get the parameters it might needs. This was very wrong
because at that point it is still the old consensus set globally.
This commit changes the notify_networkstatus_changed() to be the "before"
function and adds an "after" notification from which the scheduler subsystem
is notified.
Nick Mathewson [Wed, 31 Jan 2018 19:06:37 +0000 (14:06 -0500)]
Fix a failing unit test.
When we stopped looking at the "protocols" variable directly, we
broke the hs_service/build_update_descriptors test, since it didn't
actually update any of the flags.
The fix here is to call summarize_protover_flags() from that test,
and to expose summarize_protover_flags() as "STATIC" from
routerparse.c.
David Goulet [Wed, 31 Jan 2018 15:58:11 +0000 (10:58 -0500)]
hs-v3: Remove a BUG() when storing a descriptor in the client cache
It is possible in normal circumstances that a client fetches a descriptor
that has a lower revision counter than the one in its cache. This can happen
due to HSDir desync.
Fixes #24976
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Wed, 31 Jan 2018 16:08:33 +0000 (11:08 -0500)]
ns: Call notify_networkstatus_changed() after the new consensus is set globally
In 0.3.2.1-alpha, we've added this function in order to have a way to notify
other subsystems that the consensus just changed. The old consensus and the
new one are passed to it.
Before this patch, this was done _before_ the new consensus was set globally
(thus NOT accessible by getting the latest consensus). The scheduler
notification was assuming that it was set and select_scheduler() is looking at
the latest consensus to get the parameters it might needs. This was very wrong
because at that point it is still the old consensus set globally.
With this commit, notify_networkstatus_changed() has been moved _after_ the
new consensus is set globally. The main obvious reasons is to fix the bug
described above and in #24975. The other reason is that this notify function
doesn't return anything which could be allowing the possibility of refusing to
set the new consensus on error. In other words, the new consensus is set right
after the notification whatever happens.
It does no harm or change in behavior to set the new consensus first and then
notify the subsystems. The two functions currently used are for the control
port using the old and new consensus and sending the diff. The second is the
scheduler that needs the new consensus to be set globally before being called.
Of course, the function has been documented accordinly to clearly state it is
done _after_ the new consensus is set.
Fixes #24975
Signed-off-by: David Goulet <dgoulet@torproject.org>
Roger Dingledine [Wed, 31 Jan 2018 10:26:06 +0000 (05:26 -0500)]
count flushing as channel activity
Stop adding unneeded channel padding right after we finish flushing
to a connection that has been trying to flush for many seconds.
Instead, treat all partial or complete flushes as activity on the
channel, which will defer the time until we need to add padding.
This fix should resolve confusing and scary log messages like
"Channel padding timeout scheduled 221453ms in the past."
Fixes bug 22212; bugfix on 0.3.1.1-alpha.
I think technically we could resolve bug 22212 by adding a call to
channel_timestamp_active() only in the finished_flushing case. But I added
a call in the flushed_some case too since that seems to more accurately
reflect the notion of "active".
projects / thirdparty / tor.git / log
