[tor-bugs] #10169 [Tor]: Extend OOM handler to cover channels/connection buffers
Tor Bug Tracker & Wiki
blackhole at torproject.org
Sun Jan 19 22:20:10 UTC 2014
#10169: Extend OOM handler to cover channels/connection buffers
------------------------+----------------------------------------
Reporter: nickm | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: Tor: 0.2.5.x-final
Component: Tor | Version:
Resolution: | Keywords: tor-relay oom 024-backport
Actual Points: | Parent ID:
Points: |
------------------------+----------------------------------------
Comment (by sysrqb):
Reviewed bug10169_024.
total_bytes_allocated_in_chunks still has a DOCDOC in buffers.c
I wonder if END_CIRC_REASON_RESOURCELIMIT can be used to perform a
modified sniper-based oracle attack if there's another way to fill the
remaining 10% when the 90% memory usage is reached.
It might be useful to the relay operator if Tor says how many circuits
remained alive after circuits_handle_oom runs, e.g. modify the log notice
at the end of that function.
{{{
int n_circuits_alive = smartlist_len(circlist) - n_circuits_killed;
log_notice(LD_GENERAL, "Removed "U64_FORMAT" bytes by killing %d "
"circuits, %d circuits remain alive.",
U64_PRINTF_ARG(mem_recovered), n_circuits_killed,
n_circuits_alive);
}}}
Maybe the comments for circuit_get_streams_max_data_age and
marked_circuit_streams_free_bytes should notate that they are helpers for
circuit_max_queued_data_age and marked_circuit_free_stream_bytes,
respectively?
Is it possible that when the stream buffers are "aggressively freed" using
chunk_free_unchecked() they may not actually be freed, but prepended to a
freelist and, as a result, less memory is actually freed in
circuits_handle_oom() than is expected?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10169#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list