[tor-bugs] #23712 [Core Tor/Tor]: sched: DESTROY cell on a circuit bypasses the scheduler

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Oct 2 22:08:48 UTC 2017


#23712: sched: DESTROY cell on a circuit bypasses the scheduler
--------------------------+------------------------------------
 Reporter:  dgoulet       |          Owner:  (none)
     Type:  defect        |         Status:  needs_review
 Priority:  Medium        |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  tor-sched     |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------
Changes (by dgoulet):

 * status:  new => needs_review


Comment:

 See branch: `bug23712_032_01`.

 Ok this might look like a very simple fix but it is really not.

 For KIST, this is what we _need_ to do else this process of appending a
 DESTROY cell bypasses the scheduler and can trigger KIST to try to flush
 an empty channel which could be one of the source of #23676. The following
 lists the possible channel state it can be when the destroy cell is
 appended and the scheduler notified:

  i. if in `WAITING_FOR_CELLS`, all good, we will get scheduled
  ii. KIST can't let unscheduled channel in `WAITING_TO_WRITE` so we can't
 be calling "waiting for cells" on a "waiting to write" channel.
  iii. KIST doesn't put channel in `IDLE` state
  iv. `PENDING` state, can't escape the scheduler, like (ii).

 For the Vanilla kernel:

  i. if in `WAITING_FOR_CELLS`, all good, we will get scheduled
  ii. if in `WAITING_TO_WRITE`, it means we have data in the queue but
 can't put them in the outbuf because it is full. The `flushed_some()`
 function will call the "wants to write" event when the outbuf is flushed
 to the network and thus the DESTROY cell will ultimately get drained.
  iii. `PENDING` state, can't escape the scheduler.
  iv. if in the `IDLE` state, it means we have no more cell in the queue
 and the outbuf is full, the channel is put in `WAITING_TO_WRITE` state so
 (ii) applies to this case that is the "wants to write" event will trigger
 a flush of the destroy cell at some point when the outbuf is drained.

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


More information about the tor-bugs mailing list