| Age | Commit message (Collapse) | Author |
|---|
|
This started as a response to ticket #40792 where Coverity is
complaining about a potential year 2038 bug where we cast time_t from
approx_time() to uint32_t for use in token_bucket_ctr.
There was a larger can of worms though, since token_bucket really
doesn't want to be using wallclock time here. I audited the call sites
for approx_time() and changed any that used a 32-bit cast or made
inappropriate use of wallclock time. Things like certificate lifetime,
consensus intervals, etc. need wallclock time. Measurements of rates
over time, however, are better served with a monotonic timer that does
not try and sync with wallclock ever.
Looking closer at token_bucket, its design is a bit odd because it was
initially intended for use with tick units but later forked into
token_bucket_rw which uses ticks to count bytes per second, and
token_bucket_ctr which uses seconds to count slower events. The rates
represented by either token bucket can't be lower than 1 per second, so
the slower timer in 'ctr' is necessary to represent the slower rates of
things like connections or introduction packets or rendezvous attempts.
I considered modifying token_bucket to use 64-bit timestamps overall
instead of 32-bit, but that seemed like an unnecessarily invasive change
that would grant some peace of mind but probably not help much. I was
more interested in removing the dependency on wallclock time. The
token_bucket_rw timer already uses monotonic time. This patch converts
token_bucket_ctr to use monotonic time as well. It introduces a new
monotime_coarse_absolute_sec(), which is currently the same as nsec
divided by a billion but could be optimized easily if we ever need to.
This patch also might fix a rollover bug.. I haven't tested this
extensively but I don't think the previous version of the rollover code
on either token bucket was correct, and I would expect it to get stuck
after the first rollover.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
|
|
|
|
Bug 1: We were purporting to calculate milliseconds per tick, when we
*should* have been computing ticks per millisecond.
Bug 2: Instead of computing either one of those, we were _actually_
computing femtoseconds per tick.
These two bugs covered for one another on x86 hardware, where 1 tick
== 1 nanosecond. But on M1 OSX, 1 tick is about 41 nanoseconds,
causing surprising results.
Fixes bug 40684; bugfix on 0.3.3.1-alpha.
|
|
|
|
Typos found with codespell.
Please keep in mind that this should have impact on actual code
and must be carefully evaluated:
src/core/or/lttng_circuit.inc
- ctf_enum_value("CONTROLER", CIRCUIT_PURPOSE_CONTROLLER)
+ ctf_enum_value("CONTROLLER", CIRCUIT_PURPOSE_CONTROLLER)
|
|
|
|
|
|
Using a standard ending here will let other tools that expect
markdown understand our output here.
This commit was automatically generated with:
for fn in $(find src -name '*.dox'); do \
git mv "$fn" "${fn%.dox}.md"; \
done
|
|
This is an automatically generated commit, made with:
find src -name '*.dox' | \
xargs perl -i -ne 'print unless (m#^\s*/?\*\*/?\s*$#);'
|
|
(This copies documentation from doc/HACKING/design, and edits for
concisensess and clarity.)
|
|
This commit was automatically generated with:
find src -name '*.dox' |xargs perl -i -pe 's{\@dir ([^/])}{\@dir /$1};'
|
|
This includes app, core, feature, lib, and tools, but excludes
ext, test, and trunnel.
This was generated by the following shell script:
cd src
for dname in $(find lib core feature app tools -type d |grep -v \\.deps$); do
keyword="$(echo "$dname" |sed -e "s/\//_/" )"
target="${dname}/${keyword}.dox"
echo "$target"
cat <<EOF >"$target"
/**
@dir ${dname}
@brief ${dname}
**/
EOF
git add "$target"
done
|
|
|
|
Merged modified lines from bug31615_040, and unmodified lines
from maint-0.4.1.
|
|
Fix levels for subsystems that depend on log/err
* winprocess (security) doesn't use err:
* call windows process security APIs as early as possible
* init err after winprocess
* move wallclock so it's still after err
* network and time depend on log:
* make sure that network and time can use logging.
* init network and time after log
Add comments explaining the module init order.
Fixes bug 31615; bugfix on 0.4.0.1-alpha.
|
|
|
|
|
|
|
|
|
|
This mechanism isn't perfect, and sometimes it will guess wrong,
but it will help our automation.
|
|
|
|
There's an incorrect comment in compat_time.c that suggests we call
FreeLibrary() before we're done using the library's functions.
See 29642 for background.
Closes ticket 29643.
|
|
Explain what "monotonic" actually means, and document some results that
have surprised people.
Fixes bug 29640; bugfix on 0.2.9.1-alpha.
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Mike Perry <mikeperry-git@torproject.org>
|
|
Co-authored-by: George Kadianakis <desnacked@riseup.net>
|
|
|
|
|
|
|
|
|
|
|
|
Fun fact: these files used to be called log.[ch] until we ran into
conflicts with systems having a log.h file. But now that we always
include "lib/log/log.h", we should be fine.
|
|
|
|
These were mostly cases where our previous macros had been casting,
and the values that we were trying to printf were not in fact
uint64_t.
|
|
The standard is printf("%"PRIu64, x);
|
|
Recent code movement from refactoring missed some includes that seem
to be necessary on macOS.
|
|
We need to use lib/fs/winlib.h here so that we can use
GetTickCount64.
I would love to declare that XP is dead, and everybody has
GetTickCount64.
|
|
|
|
|
