[tor-bugs] #7912 [Tor]: Cells that don't get inserted into cell queues can clog connection flushing

[Tor Bug Tracker & Wiki]

#7912: Cells that don't get inserted into cell queues can clog connection flushing
------------------------------------+---------------------------------------
 Reporter:  asn                     |          Owner:                    
     Type:  defect                  |         Status:  needs_review      
 Priority:  major                   |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor                     |        Version:                    
 Keywords:  tor-relay 023-backport  |         Parent:                    
   Points:                          |   Actualpoints:                    
------------------------------------+---------------------------------------

Comment(by andrea):

 Replying to [comment:30 nickm]:
 > Replying to [comment:29 nickm]:
 > > >you have circuit_set_p_circid_chan() clearing circ->p_delete_pending
 and marking the circuit ID unusable on the old channel, but
 circuit_set_n_circid_chan() *sets* circ->n_delete_pending in the analogous
 case (which is a no-op since the test for the if already implies that).
 That seems unlikely to be correct.
 > >
 > > Okay; will investigate and fix.
 >
 > Added a fixup commit; thanks!

 Fixup looks fine.

 > > >  we might want to consider more flexible policy than alternation.
 > >
 > > Agreed.
 >
 > (We should open a ticket for this; it feels like an 0.2.5 thing)
 >
 > > > How thoroughly has this been tested, given the number of different
 bits of code it touches?
 > >
 > > Hardly at all.  I *think* I ran it on a chutney network and it didn't
 explode, but that doesn't mean much.
 >
 > I can try it on another chutney network.  How else should we check?  I'd
 be especially worried about bugs that prevented deletes from getting sent
 entirely.  Any ideas about how can we audit for those?

 Hmmmm - do you mean bugs where *no* deletes or significantly fewer deletes
 get sent, or are you worried about more subtle cases where once in a great
 while a delete gets stuck or lost?

 In the former case, it might be easiest to approach it statistically: add
 a log message on how many deletes have been sent out of how many cells in
 total, and compare against master.  The latter probably needs trickier
 debug output for deletes entering and leaving the queue or something like
 that.

 Maybe an easy way to spot *if* there's an issue meriting further
 investigation would be to count deletes when they enter the queue (i.e.,
 at the earliest point where this patch series changes any of the logic)
 and then when they're sent, and see if differences between the counters
 stay in a bounded range (i.e., the size of the queue under equilibrium
 conditions) or increase as the node stays running longer?

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