[tor-bugs] #28089 [Core Tor/Tor]: Exhausting our bandwidth write limit stops the connection from reading

[Tor Bug Tracker & Wiki]

#28089: Exhausting our bandwidth write limit stops the connection from reading
-------------------------+-------------------------------------------------
     Reporter:  dgoulet  |      Owner:  (none)
         Type:  defect   |     Status:  new
     Priority:  Very     |  Milestone:  Tor: 0.3.5.x-final
  High                   |
    Component:  Core     |    Version:
  Tor/Tor                |
     Severity:  Blocker  |   Keywords:  regression, tor-relay, 034-backport
Actual Points:           |  Parent ID:
       Points:           |   Reviewer:
      Sponsor:           |
-------------------------+-------------------------------------------------
 In commit `488e2b00bf881b97bcc8e4bbe304845ff1d79a03`, we've refactored the
 block the connection on bandwidth logic and *one* typo got in, probably
 bad copy paste:

 {{{
 void
 connection_write_bw_exhausted(connection_t *conn, bool is_global_bw)
 {
   (void)is_global_bw;
   conn->write_blocked_on_bw = 1;
   connection_stop_reading(conn);
   reenable_blocked_connection_schedule();
 }
 }}}

 Notice the `connection_stop_reading()` call where it should be a _stop
 writing_ ... This has the really bad side effect of making tor stop
 reading on the socket if the write limit is reached, and because
 `read_blocked_on_bw` is not set to 1, it is never reenabled through our
 mainloop callback.

 This fix is *critical* else bytes accumulate in the kernel TCP buffers
 which can lead to OOM but also lost of connectivity with >= 0.3.4.x
 relays. One way to accumulate is the keepalive cell that bypasses KIST
 scheduler so tor sends it regardless if the kernel thinks it is OK. I'll
 open a ticket for this which is another problem.

 This is most likely fixing #27813.

 Appeared in 0.3.4.1-alpha.

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