[tor-bugs] #11476 [Tor]: Try making all memory pool and freelist code off by default, or clear-on-alloc
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed May 21 17:37:02 UTC 2014
#11476: Try making all memory pool and freelist code off by default, or clear-on-
alloc
------------------------+----------------------------------------------
Reporter: nickm | Owner: andrea
Type: defect | Status: needs_revision
Priority: normal | Milestone: Tor: 0.2.5.x-final
Component: Tor | Version:
Resolution: | Keywords: tor-relay, security, 025-triaged
Actual Points: | Parent ID:
Points: |
------------------------+----------------------------------------------
Comment (by nickm):
> because mp_pool_get() takes a cell pool as an argument, so I'd also have
to leave 'static mp_pool_t *cell_pool = NULL;' in relay.c outside the
#ifdef if I were keeping the call to mp_pool_get() but making it wrap
tor_malloc_zero().
That's not so bad IMO; you'd just need to have mp_pool_t be semantically
"This is a memory pool if ENABLE_MEMPOOLS is set; this is a placeholder
object if it isn't."
> Counter-suggestion: replace mp_pool_get() calls in relay.c with
relay_alloc_cell() or something like that, which is #defined to either
mp_pool_get(cell_pool) or tor_malloc_zero() as appropriate?
I think that approach is okay too. The thing I don't want to have happen
is multiple instances of
{{{
#ifdef ENABLE_MEMPOOLS
foo();
#else
bar();
#endif
}}}
scattered throughout the codebase. That's a recipe for hard-to-maintain
code IMO. Ideally, when there's an ENABLE_foo, its effects should be
isolated by a function abstraction at some level, though IMO the exact
level is not super critical.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11476#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list