Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Tor Tor
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 823
    • Issues 823
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 33
    • Merge requests 33
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Core
  • TorTor
  • Issues
  • #28089
Closed
Open
Created Oct 17, 2018 by David Goulet@dgoulet🔆Owner

Exhausting our bandwidth write limit stops the connection from reading

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 legacy/trac#27813 (moved).

Appeared in 0.3.4.1-alpha.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking