[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:38:30 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 andrea):

 Replying to [comment:12 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.

 Okay, fine by me.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11476#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list