[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