mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-20 10:12:15 +01:00
conn: Stop writing when our write bandwidth limist is exhausted
Commit 488e2b00bf
introduced an issue, most
likely introduced by a bad copy paste, that made us stop reading on the
connection if our write bandwidth limit was reached.
The problem is that because "read_blocked_on_bw" was never set, the connection
was never reenabled for reading.
This is most likely the cause of #27813 where bytes were accumulating in the
kernel TCP bufers because tor was not doing reads. Only relays with
RelayBandwidthRate would suffer from this but affecting all relays connecting
to them. And using that tor option is recommended and best practice so many
many relays have it enabled.
Fixes #28089.
This commit is contained in:
parent
b5731cdf2e
commit
2000d04cb6
6
changes/ticket28089
Normal file
6
changes/ticket28089
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
o Major bugfixes (relay):
|
||||||
|
- When our write bandwidth limit is exhausted, stop writing on the
|
||||||
|
connection. Previously, we had a typo in the code that would make us stop
|
||||||
|
reading leading to relay connections being stuck indefinitely. Fixes bug
|
||||||
|
28089; bugfix on 0.3.4.1-alpha.
|
||||||
|
|
@ -3111,7 +3111,7 @@ connection_write_bw_exhausted(connection_t *conn, bool is_global_bw)
|
|||||||
{
|
{
|
||||||
(void)is_global_bw;
|
(void)is_global_bw;
|
||||||
conn->write_blocked_on_bw = 1;
|
conn->write_blocked_on_bw = 1;
|
||||||
connection_stop_reading(conn);
|
connection_stop_writing(conn);
|
||||||
reenable_blocked_connection_schedule();
|
reenable_blocked_connection_schedule();
|
||||||
}
|
}
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user