[tor-bugs] #24668 [Core Tor/Tor]: sched: scheduler_compare_channels() function will never pick a channel with no active circuis.

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Dec 22 17:51:58 UTC 2017


#24668: sched: scheduler_compare_channels() function will never pick a channel with
no active circuis.
----------------------------------------------+----------------------------
 Reporter:  dgoulet                           |          Owner:  (none)
     Type:  defect                            |         Status:  new
 Priority:  Medium                            |      Milestone:  Tor:
                                              |  0.3.3.x-final
Component:  Core Tor/Tor                      |        Version:
 Severity:  Normal                            |     Resolution:
 Keywords:  tor-sched, tor-channel, tor-cell  |  Actual Points:
Parent ID:                                    |         Points:
 Reviewer:                                    |        Sponsor:
----------------------------------------------+----------------------------

Comment (by dgoulet):

 Replying to [comment:1 arma]:
 > Replying to [ticket:24668 dgoulet]:
 > > To fix this one, we probably have to fix ewma_cmp_cmux() to look at
 destroy cells too (somehow).
 [snip]
 > How hard would it be to add the circuit to the active_circuit_pqueue
 when it has a non-empty destroy queue? Then it would at least get a chance
 to be considered, even if we aren't load balancing in an optimal way
 (whatever that means) between sending data cells and destroy cells.

 Actually, we can't because it is possible for the `circuit_t` object to be
 freed or about to be freed. We often send DESTROY cells from the
 `about_to_free()` circuit.

 Thus this DESTROY queue keeps what needs to be sent while tor get rid of
 the circuit object.

 It is imo a hard problem because an EWMA circuit priority is a moving
 value over time for a specific circuit while DESTROY cells, once put in
 the queue, can't have a priority that relates to the moving one or even to
 the current circuit alive. Thus the FIFO design maybe?

 Because we could decide that when we send a DESTROY cell, we flush the
 entire circuit queue (like we do now in all cases), append the DESTROY and
 then keep the circuit object alive until it gets scheduled by the EWMA
 policy and only then we free(). That is quite an added complexity but
 would finally make the scheduler handle those cells instead of being
 bypassed.

 Else we need to go in crazier algorithm with multiple priority queues
 because prioritizing DESTROY cells is important for many reasons.

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


More information about the tor-bugs mailing list